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1.0 INTRODUCTION AND SUMMARY 

1.1 INTRODUCTION 

GSFC is implementing a capability to support non-time-critical data 
from Spacelab payloads. It does not include the support of OFTs and data 
processing for specialized payloads such as life sciences or space processing. 
The data processing functions to be performed are essentially the same as 
provided by the Information Processing Division (IPD)for automated Earth orbiting 
spacecraft. These functions both remove perturbations introduced by the 
acquisition system and verify, f ormat, an d forward the data_ to the experi - 
menter's facility. The reduction, analysis, and long-term archiving functions 
are not described in this document because they are not the responsibility of 
the data processing facility. 

In general, the flow of non-time-critical Spacelab payload data is 
as follows (see Figure 1-1) the instrument digital data is time division 
multiplexed and transmitted on the wide band Ku-band link via TDRS and the 
"bent pipe" to the GSFC processing facility. The salient characteristics of 
this operation are the following: 

• Bit rates up to 50 Mbps can be accommodated. 

» Real-time and on-board tape recorded data can be telemetered 
on wide band link. 

9 No ground recording capability exists at TDRS or GSTDN 

ground stations. A Domsat channel is used to relay the data 
to GSFC. 

9 Payload data for POCC real time processing analysis are 
telemetered via the wideband link or are stripped out from 
the wide band link at JSC. 

• The wide band link contains all the required ancillary 
data. All data required for processing will be contained 
in that bit stream. 

In the Spacelab data processing facility, the telemetry stream is 
captured, i.e., quality checked, accounted for, and recorded in real time. 
Subsequently, not in real time, the data are processed and distributed to 
users via tape or data transmission channels. The data processing operations 
are similar to those performed in IPD on free flier data, i.e., the data are 
format synchronized, time tagged, quality checked, decommutated, etc. 


1 



SPACELAB/ 

ORBITER 



► HIGH RATE MULTIPLEXED DATA 
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FIGURE 1-1. THE SDPF WITHIN THE OVERALL 
SPACELAB/ORBITER PROGRAM 








Under the current concept, the Spacelab Data Processing Facility 
(SDPF) will consist of the following major functional elements 

1. Spacelab Input Processing System (SIPS) previously 

known as the Data Capture System 

2. Data Processing System 

3. Mass Storage System 

4. Output Processing System 

Items 2 through 4 constitute the Spacelab Output Processing System 
(SOPS). The flow of data through these elements is depicted in Figure 1-2. 

The real-time wide band data are captured in real time for the duration of the 
mission. The data capture function includes recording of the raw bit stream 
on a suitable recording medium, such as a high density tape Subsequently, 
the recorded data are transferred to a working mass store, processed, and 
delivered to experimenters. 

This study addresses itself solely to examining multiple SOPS architec- 
tures. The SIPS is not part of the SOPS architecture and will be referenced in 
this document only for the purpose of inputing data to the output processor 
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FIGURE 1-2 SOPS DATA FLOW 


4 





1.2 


SUMMARY 


This study presents different system architectures (Figures 6-3 and 
6-34). These two architectures are derived from two different "data flows" 

(Figures 6-1 and 6-2) within the SOPS. The major differences between these 
system architectures are in the position of the deconmutation function (the 
first architecture performs decommutation in the latter half of the system and 
the second architecture performs that function in the front end of the system). 
Another difference is that the first architecture uses High Density Tapes (HDTs) 
and the second uses standard 6250 bpi magnetic tapes. 

So that the performance of these architectures could be examined, the 
system was divided into five stand-alone subsystems. (Work Assembler, Mass 
Storage System, Output Processor, Peripheral Pool, and Resource Monitor). Then 
the work load of each subsystem was estimated independent of the specific devices 
(CPUs, tape drives, etc.) to be used. 

Next, the candidate devices were surveyed from a wide sampling of off- 
the-shelf devices. Then analytical expressions were developed to quantify the 
projected workload in conjunction with typical devices which would adequately 
handle the subsystem tasks. 

All of the study efforts were then directed toward preparing perfor- 
mance and cost curves for each architecture subsystem (shown simplistically in 
Figure 1-3). Because the operating points of each subsystem cannot at this time 
be set exactly, it is necessary to interpolate between specific operating points. 

For example, (See Figure 1-3), it was found that in the Work Assembler (WA) at an 
operating point, (in Mb/s.), the WA would consume between and "u^" 
resources. This range of system utilization represented a range of costs between 
"a" and "b" dollars. If the study workload estimates are too low (even up to 100%), 
then the range of costs (at Mb/s.) could still be projected to be between "a" 
and "c" dollars. This sizing technique (known as computing a subsystem's 
utilization factor "u") was applied uniformly to all architecture subsystems. 

It was found that the two architectures would function equally well. 

When each of their attributes were rated in terms of its intended function, the 
total scores of the two architectures were within (approximately) 5% of each 
other. 
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In terms of costs, however, architecture number 2 was clearly more 
advantageous. Specifically design number 2 costs between 2.177 and 3.022 
million dollars for hardware while architecture 1 costs between 2 337 and 3.400 
million dollars. 
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2.0 SOPS SPECIFICATIONS 

This section defines those specifications to be used m defining and 
analyzing various system architectures. These specifications are drawn from the 
Statement of Work, NASA/GSFC document Number X-560-77-56 entitled "Spacelab 
Payload Data Processing at GSFC," and an informal document entitled "Pulse Code 
Modulation Formats for Spacelab Experiments." Most of the specifications are 
functional in nature, but, _ where possible, quantitative jnformati on i js used. 

The statement of specifications is treated at two levels - those that 
are mandatory (as enumerated in Section 2.1), and those that are secondary or 
desirable (as stated in Section 2.2). 

One overall specification is that any system architecture must be modular 
and expandable with the minimum of difficulty. 
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2.1 


MANDATORY SPECIFICATIONS 


2.1.1 Overall System Performance 


This subsection relates to the data acquired by, contained within, and 
put out by the system. Initially, the specifications are stated as currently 
known and understood. From the quantitative information contained m that 
statement, additional data can be derived for use in later analysis. This data 
is in Section 5. 
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2. 1.1.1 Input Data 


Data are received into the SOPS from the SIPS. These data are 
both real-time and play-back data (from the HDT's originally used to record 
real-time telemetry). 

The SIPS, as illustrated in Figure 2-1, will be procured separately from 
the SOPS High-rate Spacelab data will enter the SIPS at a maximum rate of 
50 Mb/s. These data including GMT from the Spacelab are captured on high density 
tape recorders (HDTRs) m real time. At the same time that the incoming data 
are captured on the HDTRs, the data goes through a High Rate Data Demultiplexer 
(HRDM) where the original 18 Spacelab data channels plus the associated GMT are 
demultiplexed. The Frame Synchronizers (FSs 1 through 19) block incoming data 
and append the most recent GMT to the framed data. The outputs of the FSs are 
then sampled by the SIPS_CPU (a minicomputer) for quality and other attributes. 

A running Quality Control summary is generated, and if the sampled QC falls 
below a predetermined level, a status message is created and sent to the Spacelab 
POCC at JSC. 


Operationally, it is expected that low-and medium- rate experiment data 
will be passed onto the SOPS in real time. The high-rate experiment data will 
be slowed down in the SIPS and played back into the SOPS 'for subsequent process- 
ing (during the interval of time when the early Space! abs cannot communicate 
with the ground - approximately 20 to 30% of an orbital time segment). 

In the SIPS, the data is frame-synchronized and blocked as telemetry 
frames. The format'*' of the SIPS output data is shown in Figure 2-2. 

The following parameters are applicable: 

• Major frame rate is a binary function. 

t If the size of a minor frame is m, and the size of a major 

frame is M, then 
4m-? M ^ 256 m 
111^4096 bits 

or 

m? 512 bytes 

• Minor frame efficiency e 
70% < e < 90% 

^Informal Documentation, "Pulse Code Modulation Formats for Spacelab Experiments" 
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FIGURE 2-1. SIMPLIFIED SIPS BLOCK DIAGRAM 
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MILLISECONDS** 


MISSION ID 


N/U = NOT USED 

*9 BITS FOR DAYS OF YEAR IN BINARY 
**27 BITS FOR MILLISECOND TIME IN BINARY 


FIGURE 2-2. FRAME HEADER STRUCTURE FOR SPACELAB EXPERIMENT TELEMETRY 



The data output from the SIPS is presented to the SOPS on 19 separate 
channels. Of these, 18 contain frame blocked experiment data and will appear 
in time as shown in Figures 2-2 and 2-3, 

These frames will contain the following: 

© Experiment data 

o Experiment mode 

• Mission ID 

• Date and time 

o Data quality check (TBD) information supplied by the DCS 

✓ 

These data are characterized as follows. 

© Peak Data Rate - 48 Mb/s 

9 Average Data Rate - 4 to 8 Mb/s 

12 

e Data volume/seven day mission - 2 to 5 x 10 bits 

a An experiment mix profile as shown in Table 2-1 

Of the remaining lines, two contain data from the Experiment I/O Serial 
Channel and the Subsystem I/O Serial Channel and will be received at the same 
time in a format similar to the first 16 data lines. These two data lines contain. 

a Other experiment data (not to exceed 1 KHz) 
a Attitude data (every 2 sec) 

• Position data (every 2 sec) 

a Other TBD ancillary data are characterized 
as fol 1 ows : 

9 Peak Data Rate - TBD 

a Average Data Rate (either 25.6 Kb/s or 51.2 Kb/s) 

9 Data Volume/mission - TBD 
© Format - See Figure 2-4 

The remaining line supplies GMT to the SOPS and appears in the same 
format with the following characteristics* 

a Update Rate - 10 ms 

t Data Rate - on demand 

© Format - See Figure 2-2 
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FIGURE 2-3. TIME RELATIONSHIP OF SOPS INPUT LINES 


TABLE 2-1. A TYPICAL SL EXPERIMENT PROFILE 


EXPERIMENT 

GROUP 

BIT RATE RANGE 

# EXPERIMENTS 
(TIME ON) 

AVERAGE BIT RATE 
OF EXP. GROUP 

% TIME ON 

BIT RATE 
(MISSION AVG) 

A 

10 - 30 MBS 

1-2 (part time) 

20 MBS 

2.5 - 5 

1. MBS 

B 

1 - 10 MBS 

1-4 (part time) 

5 MBS 

2.5 - 10 

.5 MBS 

C 

.1- 1 MBS 

4 - (full time) 

500 KBS 

50 - 100 

2.0 MBS 

D 


8 - (half time) 




E 

IQ - 100 KBS 

10 - (full time) 

40 KBS 

100 

.4 MBS 

F 

<10 KBS 

20 - (full time) 

5 KBS 

100 

, .1 MBS 











NOTE 16 BITS/CHANNEL, 16 BITS/DATA WORD 


FIGURE 2-4. EXPERIMENT AND SUBSYSTEM I/O CHANGES MINOR/MAJOR FRAME FORMATS 


To summarize, the SOPS must, during its data input phase, build minor 
frames, build major frames, and build buffer block data (associated with either 
blocks of minor frames or blocks of major frames sent to the mass storage 
system). The building of major frames (projected to be typically between 16 
to 32 minor frames per major frame out of a possible 100 minor frames per major 
frame) should include fill data (for missing minor frames with appropriate 
fill flags set). When blocks of data are assembled (groups of minor frames or 
major frames), information such as the following should be generated: 

« Block count 

o Experiment ID(s) 

a GMT time 

s Experiment mode 

9 Number of minor frames per major frame 

a Data quality flags 

a Block statistics 
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2. 1.1. 2 Output Data 

Output data is transmitted to experimenters as a set of "mission files" 
where each file contains all data relevant to a specific experiment. 

The media for transmission will be: 

s 1600 bpi Computer Compatible Tape 

§ 6250 bpi Computer Compatible Tape 

s High density tape 

8 56 Kb/s circuit and packet switched wire grade 
communication lines 

The relevant data contained in the mission files will be: 

e Experiment data 

o Data quality information 

a Atti tude data 

» Position Data 

s Time validation information 

e Ancillary telemetry data as required 

• SOPS accounting data 

The volume of output data is characterized as: 

9 1600 bpi CCT - 50% to 10% 

8 6250 bpi CCT - 20% to 25% 

9 HDT - 10% to 15% 

a 56 Kb/s line - 20% to 50% 

As an off-line function, data "for each experiment _must be available for 
6 to 12 months after completion of the mission. 


18 



2. 1.1.3 System Throughput 


The system throughput is defined in terms of the maximum average input 
data rate, which is 8 Mb/s. The average throughput data rate will be between 
0.5 and 1 times this rate (i e., between 4 Mb/s and 9 Mb/s). Note* mission 
duration is projected to be between one week and one month. The time allowed 
for output processing is projected to be between two weeks and two months. 

An instantaneous peak input data rate of up to 50 Mb/s will be supplied 
by the SIPS. This rate may be slowed down to any required value as long as the 
average throughput rate is not reduced. 
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2.1..2 Data Processing 

This group of mandatory specifications consitute the primary 
functions performed on incoming Space! ab data. The order in which they are 
presented in this section does not imply a mandatory data flow. 

2.1.2.X Input Data Accounting 

The data accounting functions will be required to record both the 
input file statistical information and output file statistical information. 
Input file accounting tracks data such as: 

• flags from the data capture system 

• file start and stop times 

a file size 

• file location 

0 file name 

s creati on date 

A "file" is defined as a homogeneous collection of experiment data 
from only one experiment. 
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2. 1.2. 2 Output Data Accounting 

This function relates to the ability to retain information about the 
experimenter files and information regarding facility production status. This 
function also provides the capability for generating a series of accounting 
reports for the SOPS. Reports, will be generated to determine the content of 
the telemetry, Ephemeri s/Atti tude and decommutation data files processed through 
the system. 

The accounting processor will be used in conjunction with the query 
system, to locate and bring data on line for processing from past or present 
Spacelabs. The data base inquiry system (Query) will provide the capability 
of interrogating the data base directories for information concerning the 
different data files. The information returned should contain at least start 
and stop time of data, location of data (on line file name or off line tape 
and file no.), and general status pertinent to the inquiry. This accounting 
information is to be available for any Space! ab up to one year after mission. 

As a minimum, the accounting application would: 

• Keep records of all input data on a file basis 

e Keep records of all output data on a file basis 

9 Inform the user of any missing data 

® Provide production status data 

« Keep records of previous spacelabs for at least one year 
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2.1. 2.3 Quality Check 


Quality checks on data within the SOPS would, as a minimum, 

assess, both input and output quality. Input data quality 

assessment shall consist of but not be limited to: 

• Identifying missing or incomplete data frames 

• Identifying the position of missing or incomplete data frames 

• Identifying error codes passed on to the system by the SIPS 

Output data quality assessment shall consist of but not be limited 
to* >• 

o Identifying missing or incomplete data frames 

• Identifying the position of missing or incomplete data frames 

o Identifying error codes passed on to the system by the SIPS 

a Identify all subsequent errors unique to output data 

processing 
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2 . 1 . 2 . 4 Decommutati on 


The decommutati on process produces ordered experiment data files. 

The input data is decommutated after it has been "edited". The decommutation 
process shall be performed according to a decommutation "map", which identifies 
all commutated data elements as received from the SIPS. The merging of ancillary 
data (as specified in another section) may be performed in parallel with this 
function. 


In addition to decommutating the experiment data, the following shall 
also be performed. 

a Scrt by Experiment 

a The 16 experiment channels from the SIPS could be 
either dedicated to one experiment or contain 
telemetry frames from several experiments. 

• The sub-system and experiment I/O channels will 
be multiplexed with the very low-rate experiment 
telemetry, E/A, and experiment ancillary data. 

o Sort Ephemeris and Attitude data _ 

• The E/A data is multiplexed in either the subsystem 
or experiment I/O channels - 

s The E/A data will be received every 2 seconds. . 

a The E/A data will be expanded to produce parameters 

to meet the different experimenter needs 

• Update the directory and accounting files 



.2. 1.2. 5 Merge Ancillary Data 

The ancillary data for each experiment will be found commutated in the 
experiment I/O and subsystem I/O serial channels: Data from a particular expe- 

riment will be decommutated from each frame and collected until a predetermined 
number of frames have been processed. These experiment words will be formed into 
a single block for output to the appropriate experiment output device. Each 
frame will be of one second duration-, a single time tag at the beginning of the 
block will be sufficient to correlate all the data to time throughout the record. 

The record will consist of sequential frames of a particular experiment 
with given parameters occurring in the same word location of each frame in the 
record. 
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2. 1.2. 6 Data Storage 

The data storage functions will be handled through the operating 
system's file management system. On-line data storage is required m the SOPS 
for~ 

9 System and user software 

9 The accounting system 

• Directories 

• Intermediate storage of position/attitude files 

» Intermediate storage for the different experiment 
ancillary data 

e Various telemetry and decommutation maps 

9 Quick Look Experiment files 

» Formatted data for the GSFC POCC 

As a minimum, the system will 

9 Provide the user application programs with a set 
of procedures for creating files and accessing 
files by way of direct or sequential access methods 

§ Automatically allocate, log, and record files on the 

mass storage system 
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2. 1.2.7 Data Edit 


Prior to data editing, telemetry data enters the SOPS from the SIPS in 
the form of 16-bit data words present on each of the DCS output channels. These 
data are not entirely usable in the decommutation process for four reasons: partial 

minor frames (or major frames) may exist, time gaps may not be filled in, time 

/ 

tagging data may be in error, and the major frame structure may be defective. 

The purpose of data editing is to arrange these data into usable major frames, 
to attach verifi_ed_ time codes and quality flags, and to prepare these data 
for eventual separate experiment data files. The specific data editing func- 
tions to be performed are: 

a Verify minor frame structure (build if required) 

a Verify major frame structure (build if required) 

a Insert fill data for missing frames and set appropriate flags 

a Verify time tags (correct time if required) 

a R emov e overlapping telemetry data when required 
a Order data chronologically when required 
a Add data quality flags 

a Verify the header record (build if required) 

In general, data editing consists of building experiment data into 
major frames, validating time, removal of overlapping data, summarizing, 
generating fill data (when required}, and other related editing functions. De- 
tailed descriptions follow. 
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2. 1.2. 7.1 Time Validation Functions 


GMT received by the SIPS and SOPS are in units of 10 ms. As illus- 
trated in Figure 2-5 time t + 10 ms is tagged to frame "a", even though a 
portion of frame "a" may be coincident with t + 20 ms. The time-tagging of 
framed data is performed by the SIPS. It should be noted that if frame sizes 
are '‘small" (as illustrated at the bottom of 2-5), frame "d" and “e" are timed- 
tagged at t + 10 ms. The time validation function will perform as a minimum 
higher- order corrections to correct for clock drift. This data will be provided 
to the SOPS. (These hi gher-order corrections could be illustrated as shown in 
Figure 2-6). 



GMT 


+TiME 


"LARGE" 

FRAME 


"SMALL" 

FRAME 



+TIME 


+TIME 


FIGURE 2-5. TIME TAGGING OF DATA 



FIGURE 2-6. HIGHER ORDER TIME CORRECTION FUNCTION 
{A HYPOTHETICAL EXAMPLE) 
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2. 1.2. 7. 2 Removal of Overlapped Data 


One major function of the SOPS shall be the removal of overlapped 
Spacelab data and the chronological ordering of data. Figure 2-7 illustrates 
this concept. During time interval t^— * t g Spacelab data is acquired. In - 
real-time, this data is transmitted back to Earth, but for some reason the 
on-board tape recorder is activated during interval t 2 — >t g . Data recorded 
during t 2 — » tg is transmitted later during 1 7 — *• tg. The SOPS must be capable 
of purging received data interval t 2 -_^t 5 and replacing it with t 7 — » tg. 
Special attention should be placed in handling data intervals t 2 _^t 3 and 
t 4 — *.t 5 . 

2. 1.2. 7. 2 Generation of Fill 

When a sequence of data is determined to be missing and subsequent 
data processing confirms this situation, the SOPS shall insert "filler data" 
into the data set. This filler data shall be placed in the chronological 
position corresponding to the missing experiment data. Furthermore, filler 
data shall be either all ones, or all zeros, or some other pattern that cannot 
be mistaken by the user as experiment data. In any fill operation, appropriate 
indicator flags in the data set shall be set to indicate filler data in lieu 
of actual experiment data. 
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2. 1.2. 8 Ephemen s/Atti tude 

The Ephemen s/Atti tude parameters* shall be double precision with an 
accuracy commensurate with 32 bits. The ephemeris -application functions will 
as a minimum: 

9 Perform coordinate transformati ons from the given 
system to the experimenter's desired system, such 
as Geocentric Equatorial Inertial (GEI) or Solar 
Ecliptic Inertial (SEI). 

9 Replace predicted ephemeris data with definitive 
ephemeris data (and set appropriate flags to 
indicate definitive status) received from the Mission 
Control Center (MCC) of JSC. 

Ephemen s/Atti tude tapes will be produced for each NASA experimenter 
and for ESA with coverage on each tape of one or two days. The data records 
will consist of attitude (orientation), ephemeris (orbit position), and magnetic 
field vector parameters at two second intervals. These parameters will be 
derived from the Spacelab state vector, attitude vector, joint and gimbal 
angles, radiation flux, and magnetic field vector which are commutated in the 
experiment I/O and subsystem channels. The parameters will be expressed in 
appropriate coordinate systems as scaled fixed point words The scaling con- 
vention will be part of the header block at the first of each formatted output. 


*Note. The sum of all derived ephemeris and attitude data shall be 
approximately 100 values every 2 seconds (4 bytes per value). 
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2.1.3 Mass Storage 

The SOPS mass storage sizing requirements are primarily based on the 
peak and average data rates and on the time interval between data capture and 
data delivery to the experiments. 

The implications'o'f the above functional requirement are signif- 
icant. The primary objective of the SOPS' Mass Storage System (MSS) is to 
provide a facility for the compact storage of large quantities of data and to 
make this data accessible to computer systems with minimal operator handling. 
The SOPS MSS will have the following capabilities. 

9 Modularity 

- 12 

Modularity^ will be expandable from 5 to x 10 bits of data. 
Included in the capacity count is only that data which is 
generated by a host system. Any additional data generated 
for the purpose of file heading and code recovery, or due to 
recording technology are not included in this count* 

3 Capacity 

Storage capacity of each removable storage module should 

' Q 

equal or exceed 1.2 x 10 bits.* 

o Error Rates 

The unrecoverable error rates should not exceed 1 bit in 
10 9 bits. 

t 0 Technology 

The technology used in the MSS should consist entirely of off- 
the-shelf devices with field-confirmed sets of reliability 
values. 

9 Recording Media 

The recording media should be reusable and should be available 
off-the-shelf. 

*Note: This is based on 6250 bpi magnetic tape and 3330 disk compatibility. 
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2.1.4 Data Output 


This function is divided into the following operations. 

& Conversion of the decommutated data from the output processor 
format to the experimenter's computer format, e.g., IBM, CDC, 
Data General , etc. 

• Writing the experiment and ancillary data in the desired tape 
or transmitting over a communications line 

• Verification of the data output tapes before they are released 
to the experimenter 
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2.1.5 External Communications 


Output data destined for experimenters will be transmitted in many 
instances over communication lines. Such data must meet the following criteria. 

o Be capable of being transmitted over 56 Kb/s wire lines 

• Conform to circuit - switched line protocol 

• Conform to packet - switched line protocol 

Since the transmission rate is limited to 56 Kb/s, this service will 
only be available to experiments in the E and F groups (Table 2-1). These 
selected experimenters will receive their telemetry, ancillary, and Ephemeris/ 
Attitude data over transmission lines, they will not receive data tapes. 
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2.1.6 Bis cell aneous 


In addition to the functional requirements outlined earlier in this 
section, a number of other functional requirements are imposed on the SOPS. 
They can be grouped into the following classes. 

o Operations 

& Personnel 

s System Efficiency 

o Projected Lifetime 

2. 1.6.1 Operational Constraints 

The output processor hardware/software shall be designed to operate 
with a minimum number of people. The following criterion must be considered 
during the designing- 

a Ease of maintenance (hardware and software) 

• Data throughput 

o Job turnaround time 

9 Operator intervention 

e Data base save and restore 

The primary constraint upon the operation of the SOPS is assumed to be 
the restriction of productive data processing to up to three shifts per day. 
Other important constraints upon the productive capability of the system 
are* 


s The non-processing time associated with tape/mass 
storage device handling 

• The overall efficiency of the system 

• The time required to search for given Space! ab data on archive 
source media 

2 1.6.2 Personnel 

A definitive staffing/personnel study has not been completed at this 
writing. An historical staffing profile for two similar systems is provided in 
Table 2-2. 
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TABLE 2-2. HISTORICAL STAFFING PROFILES 



MAINFRAMES/PROGRAM 

Devi ces : 

Um vac 1108 

Sigma 9 
' (AE) 

CPU (Operator’s Console) 

2 

1 

TAPE UNITS 

33 

10 

PRINTER 

2 

2 

CARD READER 

2 

1 

CARD PUNCH 

1 

1 

INTERACT. TERMINAL 

12 

NA 

GRAPHICS TERMINAL 

3 

NA 

Staffing/Shift: 



SUPERVISOR 

1 

1 

COMPUTER OPERATOR 

5 

5 

TAPE LIBRARIAN 

2 

NA 

COMMUNICATIONS ENGINEER 

NA 

1 
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2.1 .6*3 System Efficiency 

Based upon past IPD experience and recognized industry practice, it 
is reasonable to expect that the SOPS will operate with a total system 
efficiency of approximately 85%. This estimate also accounts for hardware 
failures and repeated processing of products rejected in the quality control 
procedures. 
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2. 1.6. 4 Projected Lifetime 

It is projected that the SOPS shall have a lifetime in excess 
of five (5) years. During this period the SOPS shall grow in a modular 
fashion without drastic changes to its architecture. 
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2.2 


SECONDARY SPECIFICATIONS 


The following section discusses functions that are the future require- 
ments of the system. If they are feasible and cost-effective, these functions 
would be included, either wholly or partially, in the system. 


2.2.1 Quick- Look 

This function would give the experimenter the capability to access on- 
line experiment data in real-time, for data evaluation. The system must: 

§ Use a query program to interrogate the desired 
experiment data 

9 Retrieve the desired data from mass store 
via the file management system 

• Use the decom application program to format the data 

* Transmit over communications lines to the experimenter's 
computer or generate"^ quick-look tape. 
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2.2.2 External Communications Functional Requirements 

This group of functional requirements suDports two major subdivisions 
of functional requirements - query and POCC near real-time support functions. 

2.2. 2.1 Query Functions 

The query application functions will as a minimum. 

® Interrogate, the data base 

to determine the presence of information or 
file status 

a Answer all questions concerning the existence 
of data, both on/off line, for all files 
maintained under the file management system 


n 



2;2.2.2 POCC Near*Real-time Functions 


In the future it is possible that a GSFC POCC may be established. 

The POCC Near Real-time Functions will as a minimum 

s Process data directly from input lines to POCC 
« Retrieve data from mass store 
• Format the data for the POCC 
o Transfer the data to the POCC by way of 
communication lines 
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3.0 


WEIGHTING FACTORS 


In order to allow quantitative assessment of the various architectures 
in terms of their responsiveness to the stated specifications, each major speci- 
fication is given a weighting. Theweighting is expressed as an integer between 
1 (lowest) and 10 (highest) and reflects the relative importance of that 
specification. 

The mandatory specifications will fall in the range of 5 to 10, and 
the secondaries are in the range 1 to 4. 

The remainder of this section consists of Table 3-1 referenced to the 
applicable paragraphs in Section 2, with the weightings assigned and the ra- 
tionale for them explained. 
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IMBLt J-l 
ASSIGNED WEIGHTS 


SECTION 2 
PAR. NO. 

BRIEF STATEMENT 
OF 

SPECIFICATION 

ASSIGNED 

WEIGHT 

(1-10) 

RATIONALE FOR WEIGHT ASSIGNMENT 

! 1 

2.0 

* Modularity 

8 

System sizing at this time does not account for future 


« Expandability 

8 

missions, whose characteristics are unknown. 

2. 1.1.1 

« Data characterization 

9 

Average rates must be handled. 


e Experiment mix profile 

9 

This mix is only typical. 

2. 1.1.2 

8 Tapes 

10 

This is the prime method of transmission to experimenter 


a Communications 

7 

This is a secondary method of transmission. 


a Data volumes 

10 

These volumes must be supported. 

2. 1.1.3 

o Throughput 

10 

This rate must be supported. 

2. 1.2.1 

o Update input accounting 

10 

This is mandatory for obvious reasons. 

2. 1.2. 2 

o Update output accounting 

10 

This is mandatory for obvious reasons. 


a Quality check 

10 

This is mandatory for obvious reasons. 

2. 1.2.4 

o Receive and sort TLM 

10 



e Receive and sort dphemeris 
and attitude 

10 

These are givens. 


e C & A data 


Data merge will be performed by the experimenter 
given E & A tapes as well as his own. 
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I TABLE 3-1 (CONT'D) 

i 


, SECTION 2 
, PAR. NO. 

BRIEF STATEMENT 
OF 

SPECIFICATION 

I ASSIGNED 
! WEIGHT 

! (1-10) 

i 

RATIONALE FOR WEIGHT ASSIGNMENT 

! i 

‘ 2.1. 2.5 

i 

0 Creating and accessing files 

i 

i 10 

i 

i 

These are mandatory for making files and for providing 
information for accounting. 

0 Allocate, 1 log, ..and record 

10 

2.1. 2. 6.1 

a Time validation 

5 

This ensures data is tagged with correct time 

2.1. 2.6. 2 

0 Remove overlapped data 

10 

Not removing might increase output volume significantly. 

2. 1.2.7 

e Coordinate transformation 

8 

These could all be performed by the experimenter, 
given a separate orbit tape. 

0 Ancillary data 

8 

2. 1.2.8 

i Interpolate attitude 

5 

These could all be performed by the experimenter, 
given a separate attitude tape (combined with orbit). 

e Coordinate transformation 

8 

o Ancillary attitude computa- 
tions 

8 

2. 1.2. 9 

b Merge ancillary 

! ,9 

ancillary data must be merged 

2.1.3 

i Modularity , , 

1 

i 8 

! 

i 

All of the requirements are stated as mandatory function 
of the mass storage system, < 

However, later feasibility analysis may show that the 
assiqned weiqhts for features can be traded off against 
operational considerations. 

» Capacity 

! 10 

i 

a Error rates 

10 

\ 

> Technology 

1 9 

t Media 

1 

! 7 

> Maintainability 

' 9 













































| TABLE 3-1 (cdNT'D) 


; SECTION 2 
PAR. NO. 

BRIEF STATEMENT 
*0F 

SPECIFICATION 

ASSIGNED 

WEIGHT 

(1-10) 

! 

RATIONALE FOR WEIGHT ASSIGNMENT 

, ~ i 

2.1.3, cont'd 

• Availability 

8 


! 

« Interface 

8 



a Persistence 

8 



» Self-test 

8 



o Transfer rate 

10 



• Transferability 

10 


2.1.4 

• Convert to experiment format 

10 

These are all mandatory for obvious reasons. 


9 Write to tape 

10 

1 

2.1.5 

o Transmission rate 

10 



o Switched circuit 

10 

Although 2. 1.1.2 assigns a weight of 8 within that 




■ substructure, each of these are mandatory. 


@ Packet switched 

10 


2.1.6 

c Operations 

9 



o Personnel 

9 

These are required to maintain system operations. 


s Reliability and availability 

9 



9 Maintenance support 

9 


2. 1.6.1 

& Hardware 

10 

These are mandatory to retain reliable throughput. 


\ i 


1 
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T^\BLE 3-1 (CONT'D) 


, SECTION 2 
PAR. NO. 

' 

BRIEF STATEMENT 
OF 

SPECIFICATION 

ASSIGNED 

WEIGHT 

(1-10) 

RATIONALE FOR WEIGHT ASSIGNMENT 

1 i 

2.1, .6.2 

t Software 

10 

These are mandatory to retain reliable throughput. 

2.2.1 

« Quick Look 

3 

Although this is a highly desirable feature, it cannot 
be shown at this time to enhance system operation 
sufficiently to account for potential time and cost 
burdens. 

2.2.2 

• Process data from GSFC POCC 

3 

There are secondary functions, which would enhance 
the overall missions, by coordinating real-time S/C 
data with SDPF functions to give a more responsive 
assessment of experiment performance. 

• Retrieve data 

3 

• Format data 

3 

8 1 Transfer data to POCC 

3 


i 

i 

\ 

i 
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i 
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i 

i 

i 
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1 
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4.0 


OVERVIEW OF CHARACTERISTICS OF CURRENT TECHNOLOGY 


4.1 HARDWARE 

This section will present a summary of the hardware components that 
have a high probability of being used in any SOPS system design, and to present 
representative specifications that will be used in future sections of this re- 
port. The specific devices chosen were selected to approximate the state-of- 
the-art envisioned when the SOPS will be finally designed. 

4.1.1 Mass Storage System 

NASA document NASA-CR-1^-7877, entitled "Online Mass Storage System 
Detailed Requirements Document", prepared by Aeronutromc Ford Corp., dated 
2 July 1976, for the Lyndon B. Johnson Space Center, presents a functional 
requirements study that very closely parallels the requirements of the SOPS. 

In this study, exhaustive comparative studies were performed on Ampex Terabit, 

CDC 38500, IBM 3850, and CALCOMP ATL devices. It was found after verifying 
the stated results of the study, that these systems are candidates for the SOPS. 
Among these systems, the Terabit system appeared to be the most cost effective. 
Since publishing the referenced report. System Development Corporation (500 Machra 
Road, Sunnyvale, California) has taken over this product line. The costs for 
“the 'Terabit" system used in that report were somewhat lower tharrtoday'"s -market' - " 
price. Despite this, further study would show the Terabit system still to be 
a leading candidate. Table 4-1 tabulates the salient characteristics of each 
MSS studied. All of these systems have a sophisticated file management 
subsystem, and a portion of the functions m the SOPS could be off-loaded. 
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TABLE 4-1. CANDIDATE MSS STORAGE CAPACITIES 



AMPEX 

TERABIT 

CDC 38500 

CALCOMP 7110 
(0 6250 bpi) 

IBM 3850 

IBM DATA 
CELL 

Media Unit Data 
Capacity (bits) 

46.8 x 10 9 

64 X 10 6 

1.44 x 10 9 

400 x 10 6 

1.6 x 10 6 

Max. System On- 
Line Capacity 
(Bits) w/One 
Controller 

3.0 x 10 12 

2.08.x 10 12 

( 

9 x 10 12 

1.88 x 10 12 

2.56 x 10 10 

















4.1.2 Computing Equipment 

Three groups of computing equipment will be considered in this study: 
microprocessors (I), mini/midi-computers (II), and maxi -computers (III). 

They can be conveniently grouped as follows: 


Group 

Typical Machines 

For Detailed Data 
Sheets, See Tables 

I 

Intel ' s 8080 
TI ' s 9900 
Motorola's 6800 

4-2 

4-2 

4-2 

II 

Data General's ECLIPSE 
C/300 

4-3 


DEC'S PDP-11/70 

4-3 


General Automation's 16/440 

4-3 


HP's HP3000 Series II 

4-3 


Interdata's 8/32 

4-4 


Prime's 400 

4-4 


SEL's 32/55 

4-4 


Varian's V75 

4-4 

III 

DECS PDP-10 

4-5 


Honeywell's 64/60 

4-5 


IBM's 360/370 

4-5 


Umvac's 1100/40 

A -6 


CYBER's 170 

4-6 


The computers within each group represent a multiplicity of internal 
architectures and system interconnections. For the purposes of this study, 
however, each class of computing device will be characterized by one set of 
attributes. These attributes are tabulated in Table 4-7. Later in this study, 
the system architectures will be examined to determine which of these computer 
classes is most appropriate for each architecture. 
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TABLE 4-2 
MICROPROCESSORS 


MANUFACTURER & MODEL 


DATA FORMATS 
Word length, bits 
Fixed-point operand length, bits 
Instruction length, bits 

MAIN STORAGE 
Storage type 

Cycle time, imcroseconds/word 
Access time, imcroseconds/word 
Minimum capacity, words 
Maximum capacity, words 
Parity checking 
Error correction 
Storage protection 

CENTRAL PROCESSOR 
No of accumulators 
No. of md^( registers 
No of directly addressable words 
No of addresssing modes 
Control storage 

Add time, microseconds 
Hardware multiply/divide 
Hardware floating point 
Hardware byte manipulation 
Battery backup 
Real-time clock or timer 

INPUT/OUTPUT CONTROL 
Direct memory access channel 
Maximum I/O rata, words/sec 
No of external interrupt levels 

PERIPHERAL EQUIPMENT 
Floppy disk (diskette) drives 
Disk pack/cartridge drives 

Drum/fixed-haad disk storage 

Magnetic tape cassettas/cartridges 

Magnetic tape, %-mch 
Punched card input 
Serial printer 
Line printer 

Data communications interface 
CRT 

Other standard peripheral units 

SOFTWARE 
Assembler 
Compi 1 ers 
Operating system 
Language implemented in firmware 
Operating system imolemented in 
firmware 

PRICING & AVAILABILITY 
Price of CPU, power supply, front 
panel, and mm mem. in chasis 
Price of memory increment 
Date of first delivery 
Number installed to date 
COMMENTS 


msm 

TI 

9900 

MOTOROLA 

6800 


8 


16 


8 



8 


IS 


a 


8,16,24 

16 

; 8,16,24 

! 

RAM 

ROM 

PROM 

RAM 

ROM 

, PAM 

ROM 

PROM 

195 

- 

- 

- 

- 

1 0 



5 

5 

5 

- 

- 

55 

55 

55 

256 

2K 

- 

IK 

0 

0 

24 K 

0 

IK 

4K 

- 

1M 

64K 

512K 

5T2K 

512K 


No 


Optional 


No 



No 


Optional 


No 



No 


Optional 


No 



1 



8 


1 



1 


16 


1 



64K 


64K 


64 K 



3 



6 


3 



2 


2 7 


2 



No 


No 


No 



No 


No 


No 



No 


No 


No 



Yes 


Yes 


Yes 



Yes 


Yes 


Yes 



Yes 


Yes 


Yes 



Yes 

No 

No 

No 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Non resident 


2M 

16 


Yes 

Mo 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Non resident 
Yes 
Yes 
No 

No 


Yes 

No 

No 

No 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 


$2600 


J.'. 
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TABLE 4-3. MINICOMPUTERS 


SMOTM&1TY OF THE 
®M@fNAk I AGE IS POOR 


MANUFACTURER a MODEL 

Data General 
Eclipse 
C/330 

DATA FORMATS 


Word length, bits 

16 + 5 

Fixed-point operand length, bits 

16 

Instruction length, bits 

16 32 

MAIN STORAGE 


Storage type 

Core, M05 

Cycle time, microseeonds/word 

0 S, 0.7 

Access time, microseconds/ word 

0.4, 0 5 

Minimum capacity, words 

16K 

Maximum capacity* words 

2S6K 

Parity checking 

No 

Error correction 

Optional 

Storage protection 

Optional 

CENTRAL PROCESSOR 


No* of accumulators 

4 

No. of index registers 

2 

No. of directly addressable words 

32K 

No. of addressing modes 

7 

Control storage 

ROM 2K x 56 bits 

Add time, microseconds 

06 

Hardware multiply/divide 

Standard 

Hardware floating point 

Standard 

Hardware byte manipulation 

Standard 

Battery backup 

No 

Real-time dock or timer 

Optional , 

INPUT/OUTPUT CONTROL 

Standard 

Direct memory access channel 

Maximum I/O rate, words/sec 

1 25M 1 

No. of external interrupt levels 

16 

PERIPHERAL EQUIPMENT 

315K-2 SM byte* 

Floppy disk (diskette) drives 

Disk pack/cartridge drives- 

Pack St cartridge, 
2.5-736 M bytes t 

Drum-fixad-head disk storage 

Fixed-head, 
256K-2M bytes 

Magnetic tapa eassettes/cartndges 

Cassette, 1 6 KBS i 

Magnetic tape, !S-ineh 

10-72 KBS , 

Punched card input 

150-1000 cpm [j 

Serial printer 

10-165 cps 

Line printer 

240-600 Ipm 

Data communications interface 

Up to 9600 bps 

CRT 

30 char.x 24 lines, 

Other standard peripheral units 

Modular digital & 

i 

analog data control 
Si acquisition sub- 
system optional 

SOFTWARE 

Assembler Sr macro 2 
assembler 

Assembler 

Compilers 

FORTRAN, 
BASIC, ALGOL 

Operating system 

Batch, real-time 
time-sharing 

Language implemented in firmware 

No 

Operating system implemented in 

No 

firmware 

PRICING St AVAILABILITY 

330,000 (32K 

Price of CPU, power supply, front 

panel, and mm mem, in chassis 

core) 

Price of memory increment 

S4 500 (16K core) 
S3 500 (32K MOS) 

Date of first delivery 

October 1976 

Number installed to data 

1000+ (ail models) 

COMMENTS 

Extended anthme- * 
tic processor 
standard extended 
memory alloca- 
tion and protec- 
tion unit optional 
error correction 
std on MOS opt. 
on core 



16+2 

16 

16.32 43 


Cora 

0 98 

0.36 

64K 

1024K 

Standard 

No 


Optional 


2 9M 
Variable 


Cartridge St pack 
2.5-1408M bytes 
Fixed-head 
512K-8M bytes 
Cassatts 562 cps 

10-72 KBS 
285-1 200 cpm 
30-180 ops 
230-1200 Ipm 
50-56,000 bps 
80 char x 24 Unas 
DECtape 3325 
words/sec., paper 
taps reader 
paper tapa punch 


assembler 

BASIC, 
FORTRAN, 
COBOL FOCAL 
Real-time, interac- 
tive time-sharing 
No 
No 


General 

Automation 

16/440 


16 + 2 
16 

16 32, 48 


Core 

0 72 

0 225 

16K 

1024K 

Optional 

No 

Optional 


16 

8 

1 M with MAP 
11 

PROM 512 x 64 
bits 

a 78 

Standard 

Optional 

Standard 

No 

Standard 


Standard 

1M 

64-unlimited 


500K-2M bytes 
Pack 8t cartridge 
5-2400M bytes 
Ftxad head 
256K-2M bytes 
No 

20-60 KBS 
400, 1000 com 
1 0, 1 65 cps 
200-600 Ipm 
75-9600 bps 
SO char x 24 lines 
TTY, paper tape 
units, card 
punches A/D con- 
verters, digital 
I/O, plotters 
Macro assembler 

FORTRAN IV, 
BASIC, COBOL 

L 

: Batch real-time, 
time-sharing 
No 
No 


360,000 (128K 
core) 

$17,700 (64K 
core) 

NA 

NA 

Uses same tech- 
nology as PDP- 
11/45 and in- 
cludes 2048 
bytes of cache 
memory for in- 
creased perform- 
ance, disk stor- 
age St mag. tape 
penphs avail in 
packaged system 
called Oatasvstem 
570 


1 + 5 or + 1 


S 

O 7 

0 35 

64K 

256 K 

Standard 

Standard 

Standard 


20 

1 

None 

6 

ROM 10Kx32 
bits 
0 55 

Standard 

Standard 

Standard 

Standard 

Standard 


Standard 
4 5M 
To 125 


No 

Pack Si cartridge 
1 5-376 M bytes 
No 


72 KBS 
600 cpm 
30 120 Cps 
200-1250 Ipm 
To 4800 bps, syn 
80 char x 24 lines 
Paper tape units, 
punched card 
reader/punch 


Assembler & 
macro assembler 
COBOL, RPG II, 
FORTRAN IV, 
BASIC 

Batch, real-time, 
time-sharing 
Partially 
Partially 


S3.9E0 (16Kwo,dsl a"r“ 4K 
$3,000 (ISKwords) 


May 1975 
400 

Software and 
I/O compatible 
with SPC-16, 
oriented toward 
multiuser en- 
vironment 


June 1976 
225 (3GQ0 Senes) 

Asynchronous 
communications 
speeds to 2400 
bps, 3000 Senes 
II is an upgrade 
from previous 
3000CX Series, 
sold only as a 
packaged system 
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TABLE- 4-4 


MINICOMPUTERS 


MANUFACTURER St MODEL 


DATA FORMATS 
Word length, bits 
Fixad-point operand length, bits 
Instruction length bits 

MAIN STORAGE 
Storage type 

Cycle time, microseconds/word 
Access time, microseconds/word 
Minimum capacity, words 
Maximum capacity, words 
Parity checking 
Error correction 
Storage protection 

CENTRAL PROCESSOR 
No. of accumulators 
No. of index registers 
No. of directly addressable words 
No. of addressing modes 
Control storage 

Add time, microseconds 
Hardware multiply/divida 
Hardware floating point 
Hardware byte manipulation 
Battery backup 
Real-time clock or timer 

INPUT/OUTPUT CONTROL 
Direct memory access channel 
Maximum I/O rate, words/sec 
No of external interrupt levels 

PERIPHERAL EQUIPMENT 
Floppy disk (diskette) drives 
Disk pack/cartridga drives 

Drum/fixed-heed disk storage 

Magnetic tape casaettes/cartridges 

Magnetic tape, 14-inch 
Punched card input 
Serial printer 
Lina printer 

Data communications interface 
CRT 

Other standard peripheral units 



32 + 2 
32 

16,32, 43 


Cora 

03 

0 4 

32K 

256 K 

Optional 

No 

Standard 


32-256 

30-240 

256K 

7 

ROM, 1240 X 32 

bits 

0.4 

Standard 

Optional 

Standard 

No 

Optional 


Standard 
1 25M 
4-1 024 


16 + 2 or + S 
16, 32 
16 32, 43 


SOFTWARE 

Assembler 

Compilers 


Operating system 

Language implemented in firmware 
Operating system implemented in 
firmware 

PRICING & AVAILABILITY 
Price of CPU, power supply, front 
panel, and min mem in chassis 
Price of memory increment 

Date of first delivery 
Number installed to data 

COMMENTS 


32 + 4 

3, 16, 32, 64 
16,32 


MOS, bipolar cache J'° ra 
0 760 1 1 

° 6 °° iK 

4086 K 

Standard 3tan 

Optional 

Std 3 levels itan 


0 3 
8K 
256 K 
Standard 
No 

Standard 


1 (32-bit) 

2 (32-bit) 

64 K 

4 

PROM 2K X 64 
bits 
0 56 

Standard 

Standard 

Standard 

No 

Standard 


Standard 
1 25M 
64 


3 

3 

128K 

S 

PROM 4K x 48 
bits 
1 2 

Standard 

Standard 

Standard 

No 

Standard 


Standard 
16 S7M 
16-128 


16 + 2 
8, 16, 32 
16,32 

Core, MOS 
0 99, 0.66, 0.33 

64 K 
2S6K 
Optional 
No 

Standard 


3 

7 

2K 

3 

WCS,4K x 64 bits 

1 98, 1.32, 0 66 

Standard 

Optional 

Standard 

Optional 

Standard 


No 

Pack Si cartridge, 
2.5-1 024M bytes 
No 

Cassette, 1 KBS 

9- 120 KBS 
400, 1000 cpm 

10- 30 cps 
60-600 Ipm 
To 9600 bps 

80 char x 24 lines 
Paper tape units, 
A/O Si D/A con- 
verters, graphic 
display 

Assembler & 
macro assembler 
FORTRAN V, 
BASIC, COBOL 

Batch real-time 


SSI, COO (32K 
words) 

SI 9 COO (64K 
words) 

June 1975 
100 

512 words of 
writable control 
store optional, 
features mstrue 
tion look-ahead 
TaM software 
provides remote 
batch terminal 
emulators 


51 2K-2.0M bytes 
Pack Si cartridge, 
2.9-1 200M bytes 
Fixed-head. 
512K-1M bytes 
No 

To 72 KBS 
300 cpm 
165 cps 
To 600 Ipm 
To 56K bps 
80 char x 24 lines 
Paper tape A/D 
and D/A conv , 
card reader/punch 


Macro and micro 
assemblers 
BASIC, FORT 
RPG II, COBOL 
ALGOL 

Real-time, multi- 
user virtual mem 
Partially 
Partially 


No 

Pack Si cartridge 
5-320M bytes 
Fixed-head. 

1-4M bytes 
No' 

25-120 KBS 
30Q-1000 cpm 
No 

125-600 Ipm 
50K bps synch 
80 char x 24 lines 
Paper tape units, 
card punch, TTY 


Assembler St macro 
assembler 
RPG, FORTRAN 
IV, BASIC 

Batch, real-time, 
time-sharing 
No 
No 


Standard 

1M 

8-64 


No 

Cartridge St pack, 
2.34-373 6M bytes 
Fixed-head; 

123-492K bytes 
No 

20, 30 KBS 
300 cpm 
10, 165 cps 
300-2000 1pm 
To 50 K bps 
80 char x 24 lines 
Statos line of printer/ 
plotters, A/D St D/A 
converters 


Macro assembler St 
micro assembler 
FORTRAN, BASIC, 
COBOL, RPG 

Batch, real-time, 
multi-task 
No 
No 


$48 700 (64K sw ' uuu wura! 

*2000 (32K wds ) S6 ’ 30 ° (3K WOrdS) 
S22 MO (64K wds 1 0ctQbar 1975 
March i97o w a 

1300 (all models) 


325,000 (8K words) $39,000 (64K words) 


Basis for Create/ 

4 2 packaged 
business system 
virtual memory 
management sys- 
tem permits ad- 
dressing up to 
51 2M bytes per 
user, 2K-byte 
cache memory 
std , 2 to 1 
memory interleav- 
ing std 


Asynch commu- 
nications to 9600 
Ibps 


$16,000 (64 K core), 

$5 000 (SK MOS) 
August 1975 
NA 

Single- and dual-ported 
memories, odd/even 
interleaving for core 
memories standard 
TOTAL data base 
management system 
available, 


TTfV Of 1®® 
IS POOR _ 







TABLE 4-5 
MAX I COMP U 




MANUFACTURER & MODEL 


DEC 

PDP 10/1088 


HONEYWELL 

64/60 



DATA FORMATS 

* 



Word length, bits 

36 

32 

32 

Fixed-point operand length, bits 

36 or 18 (% word) 

32 or 16 

32 or 16 

Instruction length, bits 

36 

32 

16,32,48 

MAIN STORAGE 




Storage type 

Magnetic core 

MOS 

MOS 

Cycle time, microseconds/word 

95/1 0 

74/ 94 

48 

Access time, microseconds/word 

- 

- 

- 

Minimum caoacity, words 

256K 

196, 608 bytes 

1,048, 576 

Maximum capacity, words 

4096K 

786, 432 bytes 

8,388, 608 

Parity checking 

Yes 

Yes 

Yes 

Error correction 

Yes 

Yes 

Yes 

Storage protection 
CENTRAL PROCESSOR 

Yes 

Yes 

Yes 

No. of accumulators 

8 

8 

8 

No of index registers 

8 

8 

8 

No. of directly addressable words 

4M 

4M 


No of addresssing modes 

386 

195 


Control storage 

8 x 15 



Add time, microseconds 
Hardware mul ti pi y /di v i de 

Standard 

Standai d 

Standard 

Hardware floating point 

Std 

Std 

Std 

Hardware byte manipulation 

Std 

Std 

Std 

Battery backup 

No 

No 

No 

Real-time clock or timer 

Std 

Std 

Std 

INPUT/OUTPUT CONTROL 




Direct memory access channel 

Std 

Std 

Std 

Maximum 1/0 rate, words/sec 

4M 

4 2SM 

16M 

Ho of external interrupt levels 
PERIPHERAL EQUIPMENT 

7 levels, 135 trap 
instructions 



Floppy disk (diskette) drives 

Yes 

Yes 

Yes 

Disk pack/cartridge drives 

Yes 

Yes 

Yes 

Drum/ fixed-head disk storage 

Yes 

Yes 

Yes 

Magnetic cape cassettes/cartridges 

Yes 

Yes 

Yes 

Magnetic tape, H-mch 

Yes 

Yes 

Yes 

Punched card input 

Yes 

Yes 

Yes 

Serial printer 

Yes 

Yes 

<es 

Line printer 

Yes 

Yes 

Yes 

Data communications interface 

Yes 

Yes 

Yes 

CRT 

Yes 

Yes 

Yes 

Other standard peripheral units 
SOFTWARE 

Yes 

Yes 

Yes 

Assembler 




Compilers 
Operating system 
Language implemented in firmware 
Operating system implemented in 

ALGOL-60 , BASIC ,APL 



f i rmware 




PRICING & AVAILABILITY 




Price of CPU, power supply, front 
panel, and mm mem. in chasis 

$1,760,700 

$542 835 


Price of memory increment 

(32K words) $40K 



Date of first delivery 

Mat 1976 


Aug 1973 

Number installed to date 
COMMENTS 
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TABLE 4-6 
MAXI COMPUTERS 


MANUFACTURER & MODEL 


DATA FORMATS 
Word length, bits 
Fixed-point operand length, bits 
Instruction length, bits 

MAIN STORAGE 
Storage type 

Cycle time, microseconds/word 
Access time, microseconds/word 
Minimum capacity, words 
Maximum capacity, woras 
Parity checking 
Error correction 
Storage protection 

CENTRAL PROCESSOR 
No of accumul ators 
No of index registers 
No of directly addressable words 
No of addresssing modes 
Control storage 

Add time, microseconds 
Hardware multiply/divide 
Hardware floating point 
Hardware byte manipulation 
Battery backup 
Real-time clock or timer 

INPUT/OUTPUT CONTROL 
Direct memory access channel 
Maximum 1/0 rate, words/sec 
No. of external interrupt levels 

PERIPHERAL EQUIPMENT 
Floppy disk (diskette) drives 
Disk pack/cartridge drives 

Drtim/fixed-haad disk storage 
Magnetic tape cassettes/cartridges 

Magnetic tape, %-inch 
Punched card input 
Serial printer 
Line printer 

Data communications interface 
CRT 

Other standard peripheral units 

SOFTWARE 
Assembl er 
Compilers 
Operating system 
Language implemented in firmware 
Operating system implemented in 
firmware 

PRICING & AVAILABILITY 
Price of CPU, power supply, front 
panel, and mm mem. in chasis 
Price of memory increment 
Date of first delivery 
Number installed to date 
COMMENTS 
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TABLE 4-7 


COMPUTER CLASS CHARACTERISTICS 


COMPUTATION CLASS 
COMPUTATIONAL UNIT NAME 

I 

MICROPROCESSOR 

II 

MINI C 

— 

DATA FORMATS 
Word length, bits 

8 

16,32 

36 

Fixed-point operand length, bits 

8 

16,32 

36 

Instruction length, bits 

8 

16,32 

36 

MAIN STORAGE 




Storaoe type 

RAM, ROM 

CORE ,MOS 

C0RE,M0S 

Cycle time, microseconds/word 

5 

7 

6 

Access time, nncroseconds/ward 

5 

4 

- 

Minimum capacity, words 

IK 

16K 

100K 

Maximum capacity, words 

64K 

1024K 

2500K 

Parity checking 

OPT 

Optional 

Yes 

Error correction 

OPT 

Optional 

Yes 

Storage protection 

OPT 

Optional 

Yes 

CENTRAL PROCESSOR 




No. of accumulators 

1 

12 

10 

No. gf ind^< registers 

1 

8 

10 

No. of directly addressable words 

64K 

190K 

4M 

No. of addrasssing modes 
Control storage 

Add time, microseconds 

2 

7 

Yes 

7 


Hardware multiply/divide 

No 

Yes 

Yes 

Hardware floating point 

No 

Yes 

Yes 

Hardware byte manipulation 

No 

Yes 

Yes 

Battery backup 

Yes 

No 

No 

Real-time clock or timer 

Yes 

Yes 

Yes 

INPUT/OUTPUT CONTROL 




Direct memory access channel 
Maximum 1/0 rate, words/sec 

2M 

STD 
2 5M 

4M 

No. of external interrupt levels 


100 


PERIPHERAL EQUIPMENT 




Floppy disk (diskette) drives 

Yes 

Yes 

Yes 

Disk pack/cartridge drives 

No 

Yes 

Yes 

Drum/fixed-head disk storage 

No 

Yes 

Yes 

Magnetic tape cassettas/cartridges 

No 

Yes 

Yes 

Magnetic tape, %-mcn 

No 

Yes 

Yes 

Punched card input 

Yes 

Yes 

Yes 

Serial printer 

Yes 

Yes 

Yes 

Line printer 

Yes 

Yes 

Yes 

Data communications interface 

Yes 

Yes 

Yes 

CRT 

Yes 

Yes 

Yes 

Other standard peripheral units 

Yes 

Yes 

Yes 

SOFTWARE 




Assembler 


Macro Assembler 


Compi 1 ers 
Operating system 

Language implemented in firmware 
.. Operating system implemented in 
firmware 

PRICING & AVAILABILITY 




Price of CPU, power supply, front 
panel, and mm mem in chasis 
Price of memory increment 
Date of first delivery 
Number installed to date 
COMMENTS 


46K 









4.1.3 Computer Peripherals 

Table 4-8 presents the salient characteristics of those devices which 
would (probably) be chosen in an SOPS design. Each row and column of the 
table is indexed (1-12 and a-f), so that one may see (in Table 4-9) the ra- 
tionale used for each data entry. 


57 



































































TABLE 4-9 

RATIONALE FOR DATA ENTRY ON TABLE 4-8 

a-1 

Typical HDT capability 


a- 2 

Typical HDT capability 

- 

a- 3 

Typical HDT capability 


a- 4 

Typical HDT capability 


a-5 

Any size between 180 and 1024 bytes is acceptable. 


a- 6 

Typical large reel size 


a- 7 

Typical HDT capability 


a»8 

Typical HDT capability 


a- 9 

(9200 ft/reel x 12 m/ft)/120 ips = 920 sec/reel 


a-IO 

(9200 ft/reel x 12 in/ft)/180 ips - 613 sec/reel 


a-1 1 

Modified Martin-Marietta transport 


a-1 2 

Includes cost of Serial Controller Interface unit 


b-1 

For IBM 3420-8 equivalent (STC 3670): 1.25 Mb/s x 8 bits/byte = 

10 Mb/s. 

b-2 

For IBM 3420-8 equivalent (stc 3670): 1.25 Mb/s x 8 bits/byte = 

10 Mb/s, 

b-3 

Typical values 


b-4 

Typical values 


b-5 . 

Any size within range is acceptable, 


b-6 

Typi cal 


b-7 

Typical 


b-8 

(2400 ft/ reel x 12 in/ft)/45 sec = 640 ips 


b-9 

(2400 ft/reel x 12 in/ft)/200 ips = 144 sec/reel 


b-10 

As given in specifications (2400 ft/reel x 12 in/ft)/45 sec/reel 

= 640 ips) 

b-1 1 

Typical costs 


b-1 2 

Up to 8 umts/controller, typical costs 


c-1 

Tor IBM 3420-8 equivalent (STC 3670) 320 Kbytes/sec. 


c-2 

For IBM 3420-8 equivalent (STC 3670) 320 Kbytes/sec. 


c-3 

Typical values 


c-4 

Typical values 


c-5 

Any size within range is acceptable. 


c-6 

Typical 


c-7 

(320 Kbytes/sec) /1 600 bpi = 200 ips 


c-8 

(2400 ft/reel x 12 m)/45 sec = 640 ips 


c-9 

Same as b-9 
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TABLE 4-9 (CONT.) 

c-10_ _ 

_As given m specifications (2400 ft/reel x 12 in/ft)/45 sec/reel = 640 ips) 

c-11 

Use dual density tape units; same as 6250 bpi 


c-12 

Use dual density tape units; same as 6250 bpi 


d-1 

56K bits/sec. 


d-2 

56K bits/sec. 


d-3 

1024 bits/ (8 bits/byte) 


d-4 

4096 bits/ (8 bits/byte) 


d-5 

Good size for easy error recovery 


d-6 

Not applicable 


d-7 

Not applicable 


d-8 

Not applicable 


d-9 

Not applicable 


d-10 

Not applicable 


d-1 1 



d-1 2 



e-1 

For Ampex TBM, given specification (^9.6 x .58 * 5.6 mb/s) 


e-2 

1,2 M bytes/secT8 bits/byte = 9.6 mb/s. 


e-3 

Assumed (based on system utilization history) 


e-4 

Given specification (approximately 10 x 13,030) 


e-5 

Given specification 


e-6 

Gi ven speci f i cati on 


e-7 

Given specification 


e-8 

Not available 


e-9 

Not available 


e-10 

Not available 


e-1 1 

Based on 1.15 M dollars for basic system* 


e-12 

Based on 1.15 M dollars for basic system* 


f-1 

For software system that takes advantage of overlap disk operations: 
.7 (efficiency) x 6.448 Mb/s=4.515 Mb/s 

For non optimized systems. .4 (efficiency) x 6.448 Mb/s = 2.575 Mb/s 

f-2 

806 K Bytes/sec x 8 bits/byte = 6.448 Mb/s 


f-3 

Assumed (based on F-5) 


f-4 

»' \% %% 


* Note 

Contains a System Controller Processor (with disk controller 
disc drives). Data Channel Processor, Transport Driver, Data 
and a du&l transport 

and two 
Channel , 
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TABLE 4-9 


f-5 For IBM 3330 or Itel 7330+7830 : 13,030 bytes/track (19 tracks/cyl.; 

2 x 404 cyl/dnve; 200 Mbytes/drive) 

fFo r I BM 3350* 19,069 bytes/track (30 tracks/cyl.; 555 cyl/dnve; 

317.5 Mbytes/drive)]* 

For a realistic utilization of a 3330 type device, the following para- 
meters are typically used: 

Data bytes/sector 

Sectors/track 

Data bytes/track 

Tracks/cylinder 

Data words/cylinder 

Number of cylinders 

Data words/disk unit 

Rotation time 

Head move time/cylinder 

] f-6 Not applicable 

f-7 Not applicable 

f-8 Not applicable 

f-9 Not applicable 

f-10 Not applicable 

f-11 Itel 7330 

f— 1 2 Itel 7830 


*Note. 3350 Characteristics presented for information purposes only. 


256 

42 

10752 

19 

204,288 

411 

83,962,368 
1/60 sec i2% 
10.00 ms. (max) 




4.2 


SOFTWARE 


This section presents an overview of the software required to run the 
SOPS facility. This presentation is functional in nature and defines the 
requirements for one software system. Table 4-10 summarizes the estimates of 
the number of instructions required to perform the activities required by the 
specifications presented in Section 2. 

It should be pointed out that Table 4-11 presents a first-order of 
magnitude estimate for the software that is envisioned to be implemented on the 
SOPS. It is worthwhile to include at this point (for information purposes only) 
the software statistics from the HEAO-A data processing system. The HEAO system 
was estimated to perform five times as many operations per data point (i.e., 

8 bit bytes) when compared to the SOPS system design. The data rate from Space- 

3 

lab is estimated to be 1.25x10 times greater than HEAO. 

Applying experience from HEAO, Table 4-12 is offered as another software 
estimate for the SOPS. When one uses this table, the figure of merit (operations 
per data point) is computer to be "6“. This is very close to the previously 
estimated value to “5" 


The following four computations project a "figure of merit" for the 

SOPS: 

® For all minor frames: 


5 x 10 12 bits 

mission 


4096 bits 

minor frame 


1.22 x 10 9 minor frame 
mission - 


1275 lines x 1.22 x 10 9 m.f. 

m.f. mission 


1.56 x 10 12 


lines executed 
mission 


« 


For all major frames (M.F,): 

1.22 x 10 9 m.f . 

mission 


(^) 100 m.f . 

M.F. 


1.22 x 10 7 Major Frame 
mission 


* * * lines x 1.22 x 10 7 
m.f. 


MF 

mission 
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g 

6.10 x 10 lines executed 
mission 



TABLE 4-10 
SOFTWARE ESTIMATES 


FUNCTION 

Estimated Lines of Code Executed Per: 

DATA POINT MINOR FRAME MAJOR FRAME ORBIT GROUP EXPERIMENT FILE 

.1 Input Data Accounting 


50 

100 

1000 x E 

10,000 

.2 Output Data Accounting 


50 

100 

5000 x E 

50,000 

.3 Quality Check 


50 !BBH?AH 200 

50/200 

500 x E 

5,000 

. 4 Decommutate 


50 per Exp. Per MP 

0 

0 

0 

.5 Data Store 


0 

0 

5,000 x E 

10,000 

.6.1 Time Validate 


75 

0 

0 

0 

.6.2 Overlap Removal 


0 

0 

20,000 x E 

0 

.7 Ephemens 


0 

0 

20,000 x E 

0 

<c 

o’! 

o 

CO 

• 


0 

0 

5,000 x E 

0 

.9 Merge Ancill. 


0 

0(?) 100 

10,000 x E 

0 

Data Output 


0 

20 

10,000 x E 

10,000 

Quick Look 


500 

50 

(100,000 x E)AR 

(100,000 X E) AR 

GSFC POCC 


500 

50 

(5,000 x E) AR 

0 

Approximate 

Sub-Total 


1275 Lines 

Minor Frame 

500 Lines 
Major 
Frame 

(81,000 x E) 
Lines 

Orbit Group 

85,000 Lines 

Experiment 

File 


E = No. of Experiment 
AR = As Required 




TABLE 4-11. ESTIMATED COMPUTER TIME TO PROCESS 
ONE DAY'S HEAO-A DATA 


Computational Process 

Percentaqe 


EDIT 

28.3 

80 

ATTITUDE 

10.6 

30 

ORBIT 

00.4 

01 

DECOM & TAPE CHECK 

33.1 

94 

RAW ATTITUDE DECOM 

08.1 

25 

RAW PRECISION TIME 

00.4 

01 

FINAL PRECISION TIME 

00.7 

02 

MASTER DATA TAPE 

13.1 

37 

QUICK LOOK 

04.6 

13 


100. 

4 Hrs. 43 Min. 

CPU 

10.6 

0 Hrs. 30 Min. 

I/O 

89 4 

4 Hrs. 13 Min. 


100. 

4 Hrs 43 Min. 
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TABLE 4-12. SPACELAB OUTPUT PROCESSOR SYSTEM SOFTWARE 

ESTIMATES BASED ON THE HEAO OUTPUT PROCESSING 


FUNCTION 

ESTIMATED LINES OF CODE PER TIME REQUIRED 

Data point 
8 bits 

Minor frame 
4096 bits 

Mission 
5xlQ 1Z bits 

CPU (seconds 
700ns cycle 

Days for 
1 CPU 

Accounting ' 
and Quality 
Checking 

0.1 

51 

6.25 x 10 10 

.0436X10 6 

0.5 

Edit and 
Time Valida- 
tion 

1.5 

768 

9.37 x 10 10 

.56 x 10 6 

7.59 

Ephemeris/ 

Attitude 

0.5 

256 

31.2 x 10 10 

.219 x 10 6 

2.53 

Decom/Merge/ 
Remove Overlap 

2.5 

128 

156 x 10 10 

1.09 x 10 6 

12.65 

Transmission 

0.1 

51 

6.25 x 10 10 

.0436 x 10 6 

0.5 

Quick Look 

1.0 

512 

62.5 x 10 10 

.437 x 10 6 

5.0 

GSFC POCC 

0.3 

153 

18.7 x 1010 

0.13 x 10 6 

1.52 

TOTAL 

6.0 

3071 

374.6 x 10 10 

2.62 x 10 6 

30.29 
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« 


For all orbit groups: 


81 x 10 3 lines 

orbit group 


x 100 


orbits 

mission 


= 8.1 x 10 6 


lines executed 
mission ' 


q For all experiment files: 


8 ‘ 5 * 10 &les - 3.4 x 10» extended 


mission 


1 12 
The sum of all lines executed = 1.57 x 10 lines 

mission 


Therefore, the system will have a figure of merit = 


1.57 x 10 12 lines 16 bits 

A 


mission data point 


5 x 10 12 bits 


= 5 lines executed 
data point 


mission 


The software is divided into two major items, namely Data Base Management 
and Query and Executive Software. 

4.2.1 Data Base Management and Query Software 

A data base management system is defined as a software system that 
manages and maintains data that is to be processed by multiple applications. 
Such a system organizes data elements in some predefined structure, and retains 
relationships between different data elements within the data base. 
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The system encompasses a data management system, which is intended 
primarily to permit access to, and retrieval from, already existing files. 

Data Base Management Systems should provide the following functions: 

• Organize data in a predefined structure 

• Maintain access to storage and retrieval of data 
from multiple user programs 

• Maintain file accounting data 

• Have a report/request language that is easy to 
learn and use, and that will provide on-line inter- 
active query and retrieval, as well as hardcopy 
reports provided on demand. 

• Make information in computer files directly 
available to non-programmers 

a Relieve 1 . programmers of simple repetitive report 

generation'-and file maintenance tasks 

a Relieve users of the need to be concerned with 
device types, I/O processing and control, and 
file structures 

a Have computational capabilities 

• Support a variety of file structures 

« Handle multi -file processing 

9 Provide for the batching of a number of report 
requests during 'a single pass of the file(s) 

® Supply exits to the user's "own code"routmes 

9 Supply error diagnostics 

a Be available in special versions (e.g. auditing) 
to meet specialized application requirements and 
in a version that supports an interactive mode of 
operation and produces routine special purpose 
reports in predefined format 

The remainder of this subsection is a table (Table 14-11) which 
describes the characteristics of a number of commercially available Data Base 
Managers. This table is intended to show typical capabilities of modern Data 
Base Management systems without reference to the computer systems in wmcn tney , 
are intended to be installed. 
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Given the preceding DBM definitions, it appears that a conventional 
DBM system may be excessively powerful for the data bases within the SOPS. 
This unnecessary power would add significant overhead costs. The experiment 
data files are known before data enters the SOPS; they are ordered, time- 
tagged, and not shared by multiple experimenters. Only orbit and attitude 
data are envisioned to be shared by multiple experimenters. The experiment 
data "map" may be illustrated (figuratively) in Figure 4-1. 

In Figure 4-1, the GMT time-tag runs continuously and uniquely 
throughout the mission. The assignment of storage locations may be done 
dynamically as the data enters the system, or it may be predetermined by the 
SOPS resource monitor. When non-chronological data enters the system (i.e., 
tape recorded data that is transmitted at a latter time), the time-tag 
embedded m the data itself will be used in the EDIT function to reorder the 
experiment data. 
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REPRODUCIBILITY OF THE 
, ORIGINAL PAGE IS POOR 

TABLE 4-13 
DEM CHARACTERISTICS 
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e#&ODUCibility of the 
ORIGINAL PAGE IS POOR_ 


fABLE 4-13 (CONT'D.) 


System ' 

MODEL 204 

SYSTEM 2000 

TOTAL 

DATA BASE FEATURES 




Data base organization 

Hierarchical, network 

Hierarchical network 

Network 

Application languages 

COBOL. FORTRAN, PL/1, 
Assembler 

FORTRAN, COBOL PU1, 
Assembler 

COBOL FORTRAN, PU1, 
Assembler, RPG II 

Data base languages 

1FAM/II 

f 

DDL. IMMEDIATE 

D8DL, DML 

Variable-length segments 

Yes 

Yes 

Physical— no 
logical— yes 

Data base security 

Password lockout, 
log-in protection 

Password lockout, 
assigned authority 

None 

System accounting facilities 

Multi useraccountmg 
log and utilities 

Logs, statistics, 
and estimation tools 

None 

RECOVERY FEATURES 




Checkpoint/restan 

Yes 

Yes 

Yes (with TP monitor) 

Data base integrity 

Rollback and audit 
trail 

Transaction log and 
activity audit 

Logging, dump and 
restore 

OTHER SYSTEM FEATURES 




Concurrent batch/on line 

Yes 

Yes 

Yes 

Concurrent application program access 

Yes 

Yes 

Yes 

Inquiry /retrieval facility 

User Language 

System 2000 Query/ 
Update facility 

For Honeywell systems 
only 

Report generator 

User Language 

Yes 

SOCRATES 

Data dictionary support 

User-defined 

DDL 

None 

Telecommunication interfaces 

CICS, Intercomm and 
self-contained DC 

TP 2000, CICS, TSO 
Intercomm 

ENVIRON/1 CICS, TASK/ 
MASTER, Intercomm 

1 

COMMENTS 

Supports 250 physical 
files which can be 
cross referenced by 
a single user Multi 
threadng and data 
independence t 

k 

Can handle up to 9 
strings simultaneously 
with Multi-Thread 
option 

A CODASYL-Type DBMS 
Supports up to 32 levels 
of data elements and up 
to 65,000 files 
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GMT 




EXPERIMENT NUMBER 


INTERVAL 

1 

2 

3 

4 

5 

6 

9 9 9 9 

50 

a-b 

none 

none 


none 

none 

none 


none 

b-c 

A i 

none 


■ E i 

F 1 

G i 


Z 1 

c-d 

A 2 

none 


E 2 

F 2 

none 


Z 2 

d-e 

none 

B i 

c i 

E 3 

none 

none 


Z 3 

e-f 

A 3 

B 2 

° 2 

none 

none 

none 


Z 4 

f-g ■ 

none 

B 3 


none 

F 3 

none 


Z 5 

g-h 

none 

B4 

C 3 

none 

F 4 

none 


none 

h-i 

A 4 

B 5 

C 4 

E 4 

none 

G 2 


none 

l-j 

* 

« 

• 

• 

A 5 

* 

• 

• 

• 

• 

none 

« 

• 

• 

• 

C 5 

9 

9 

9 

9 

9 

’ none 

• 

• 

• 

• 

■ 

none 

• 

• 

9 

9 

9 

G 3 

9 

• 

9 

9 

9 


none 

9 

9 

9 

9 

9 


FIGURE 4-1. MASS STORAGE SYSTEM LOCATION INDEX 
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4.2 2 Executive Software 


This body of software should provide the capability for software 
development as well as for system operation, resource allocation and 
monitoring and failure detection. 

For software development the following capabilities must be 

provided: 

9 Assemblers 

t Linkers 

« Loaders 

s Editor for debugging 

9 File Managers 

9 High Level Language Compilers 

9 Desk Editor 

9 Reassignment of Peripherals 

e Interactive Capability 

A full discussion of the requirements of exectuive system management 
will be found in Section 6.2.4, which describes the Resource Monitor. 
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5.0 


DATA ANALYSIS 


The following analysis, lays .the foundation for _ _ _ 

alternative architectures as presented in Section 6 of this study. 

5.1 OPERATIONAL SCENARIOS 

Under NASA/6SFC contract NAS5-23438, Mod. 31, ORI performed a tracking 
and data satellite coverage study for the Spacelab. In the final technical re- 
port (dated Sept. 16, 1977), numerous detailed mission timelines were constructed. 
The Shuttle/Spacelab missions selected for that study included Solar Physics 
(SP), three different Earth Observations (E0) missions, and a High Energy 
Astrophysics (HEA) mission. These missions provided a diverse set of time- 
lines and are representative of the Shuttle/Spacelab missions to be flown m 
the early and mid- 1980's. 

The first mission scenario developed was for the Solar Physics (SP) 
mission, one of the least complex of the missions studied. Twelve experiments 
were projected to constitute the SP payload. The second mission analyzed was 
Earth Observations (EO). This mission presents a unique problem for the 
Shuttle/TDRS system, because the targets for this mission are highly localized, 
and any break in the Shuttle-TDRS link could result in the irretrievable loss 
of data on a particular target. Therefore, because the EO mission is so critical 
for the Shuttle/TDRS system, two additional EO missions were analyzed. The 
third type of mission studied was a High Energy Astrophysics (HEA) mission 
involving the viewing of celestial targets and a generally anti-solar orienta- 
tion for the orbiter. 


. High-rate data bursts were projected to last between 2 and 20 minutes 
(with an average of about 5 minutes per burst), the time projected between bursts 
was typically in units of hours. Assuming a seven-day mission, about 8.9 
hours of real-time for high-rate data transmissions (atu50 Mb/s) and 5 
minute burst durations, approximately (8.9 x 60 / 5 - 106.8) 100 bursts per 
mission would not be unlikely. If these bursts were equally distributed 
throughout the seven day mission, then the average time between bursts (in- 
cluding the 5 minutes of the burst itself) would be approximately (7 x 24 x 60 / 
100 = 100.8) 100 minutes. 
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This projection and previous information suggests that data entering 
The SOPS could be conveniently grouped in large units corresponding to orbits* 
of the Spacelab. The distribution of data as a function of orbit is illustra-- 
ted in Figure 5-1. In this figure, the high-rate daxa transmissions are placed 
in the segments of the time line that correspond to lulls m low-and medium- 
data transmissions. These high-rate data bursts could contain those low-and 
medium-experiment data that could not be transmitted via TDRS due to orbital 
position. Therefore, it would be very wise to defer processing low-and medium- 
rate data until the next or succeeding orbit. As is shown in Figure 5-1, the 
data captured during orbit 1 is output processed while orbit 3 data is being 

captured. Thus, the data from each orbit is processed at the best time. In 

addition, normal high-rate_data _{.i .e^.not .nlayback) may consist of low-, medium-, 
and high-rate data channels. _ ^ - 

Therefore, three operational scenarios are possible. These are illus- 
trated in Figures 5-2 and 5-3. The first scenario shows that low and medium-rate 
data is processed in real-time {between 0+ days and D days). After real-time data 
acquisition is completed, the high-rate data is processed. However, since low- 
and medium-rate data gaps have a high probability of showing up in the form of 
high rate-bursts, operationally no low-and medium-rate output products could be 
fully processed until all high-rate data Were searched and processed. This 
scenario can be discarded. 


To compensate for the above scenario's deficiencies, scenario number 2 
is proposed (as illustrated in the lower half of Figure 5-2). In this scenario, 
one would process all data in pseudo-parallel; i.e., low-and medium-rate with 'high- 
rate fill. This scenario is acceptable on all counts except that quick-look 
and near-real -time analyses are excluded. 


*Note: A Spacelab orbit is projected to be in the neighborhood of 100 minutes. 
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DATA GROUP IMO . 


LOW & MEDIUM RATE 
DATA TRANSMISSION 


HIGH RATE DATA 
TRANSMISSION 


DEFERRED GROUND DATA 
OUTPUT PROCESSING 




TIME (ORBIT NUMBER) 


FIGURE 5-1. HYPOTHETICAL DISTRIBUTION OF LOW, MEDIUM, AND HIGH 
RATE INCOMING DATA AND GROUND PROCESSING TIME 



SL DATA 

ACQUISITION TIME 

MAX PERIOD TO 
PROCESS ALL DATA 


PROCESS LOW & MED 
RATE DATA 

PROCESS HIGH 
RATE DATA 

REWORK & 
RETROSPECTIVE 

SET-UP FOR 
NEXT MISSION 


PROCESS LOW & MED 
RATE DATA 

PROCESS HIGH 
RATE DATA 

REWORK & 
RETROSPECTIVE 

SET-UP FOR 
NEXT MISSION 



TIME (DAYS) 


OD = MISSION START 

D = MISSION END, REPRESENTS A POST PROCESSING RATE OF 1 X AVERAGE DATA RATE 

2D = REPRESENTS A POST PROCESSING RATE OF 5X AVERAGE DATA RATE, LAST DAY OF 
SCHEDULED DATA PROCESSING, AND FIRST DAY OF SET-UP FOR NEXT MISSION 

3D = END OF SET-UP FOR NEXT MISSION 


FIGURE 5-2. OPERATIONAL SCENARIOS 
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SL DATA 

ACQUISITION TIME 

MAX PERIOD TO 
PROCESS ALL DATA - 


PROCESS LOW & MED 
RATE DATA 

PROCESS HIGH 
RATE DATA 

REWORK & 
RETROSPECTIVE 

SET-UP FOR 
NEXT MISSION 



TIME (DAYS) 


OD => MISSION START 

D = MISSION END, REPRESENTS A POST PROCESSING RATE OF 1 X AVERAGE DATA RATE 

2D = REPRESENTS A POST PROCESSING RATE OF 5X AVERAGE DATA RATE, LAST DAY OF 
SCHEDULED DATA PROCESSING, AND FIRST DAY OF SET-UP FOR NEXT MISSION 

3D = END OF SET-UP FOR NEXT MISSION 


FIGURE 5-3. OPERATIONAL SCENARIOS 
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Thus, scenario number 3 is proposed (as illustrated in Figure 5-3). 

This scenario has the advantage of supporting near real-time data processing, 
FOCC communications, very short data turn-around time, and a minimum amount of 
personnel staffing since facilities have to be operational (3 shifts/day) during 
the data acquisition period (0+ to D days). 
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5.2 INCONSISTENCIES OF GIVEN DATA 

On Table 2-1, there seems to be an inconsistency in the last column 
Bit Rate (mission average): the total of the column is 4Mb/s, while the speci- 
fications indicate an upper bound of 8Mb/s, which is consistent with a volume 
12 

stated at 5 x 10 bits. 

This table can be amended in two ways. First, tf the following 
computation is performed on the existing data: 

Mission Average Bit Rate (MABR) = Average bit rate of experiment group 

x number of experiments 
x% of time on. 

Thus, for group A 

MABR = 20 x 10 6 x 2 x 0.05 
= 2 Mb/s 

Performing this computation for all groups yields- 
A 2 Mb/s 

B 2 Mb/s 

C ] 4 Mb/s 

Dj 

E .4 Mb/s 

F .1 Mb/s 

TOTAL 8.5 Mb/s 

The second method involves a complete recomputation, which affects 
both the average bit rate per experiment group and the mission bit rate average. 
This appears as follows 

Given a bit rate range (BR-j through BRg) and assuming a uniform dis- 
tribution of rates in this range, the average bit rate is: 

Average group rate = BR-j + BR£ bits/sec 

2 

Now, if N is the number of experiments in the group, and P is the 
percentage of time, each is on then. 

MABR = BR 1 + BR 2 NP bits/sec 
2 
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Table 5-1 is a composite of the givens plus the amendments. Consider 
the case where incoming high-rate data must be slowed down to a point where the 
SOPS can handle it. Considering a DMA rate of 2 5M words/sec, then 16 bit words = 
40 Mb/s, and allowing an overhead of 50% to handle the data, we will use 20 
Mb/s as the peak available transfer rate. 

If we now assume that all incoming rates are cumulative, then construct 
a table of the highest peak rates which can occur per group. 

= highest rate x # of experiments 

A 50 Mb/s This is the highest the S/C supports 

B 40 Mb/s 

C* 4 Mb/s 

D* 8 Mb/s 

E 1 Mb/s 

F 0.2 Mb/s 

*Note Either C or D 

Now starting from F and summing backwards, we find that there is a 
threshold at 13.2 Mb/s, which is F + E + D + C. It can also be seen that A 
and B may not be summed as they would exceed the peak threshold. Therefore, 
they must occur on separate lines. So, we will consider a single playback 
slowed down such that A is at the defined SDPF peak rate of Mb/s, giving a 
factor of 2.5 to 1, which makes the B playback at 16 Mb/s. 

Reconsidering now the average rates for the mission, 

C+D+E+F = 4.8 Mb/s 


A = 2.0 = 0.8 Mb/s 

2.5 

B = 1.8 = 0.72 Mb/s 

2.5 

Total = 6.320 Mb/s 

If one were to consider a serial chain of events, i.e., low-rate data accumulated 

first in real-time, and high-rate data next slowed down; then this process would 
12 

take (5 x 10 bits/mission of 7 days) 9.157 days. 
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TABLE 5.1 A TYPICAL EXPERIMENT PROFILE 


EXP 

GROUP 

BIT RATE 
RANGE 
Bb/S 

RANGE 

NO. OF EXP 
PER GROUP 

AVERAGE BIT RATE OF 
GROUP Mb/S 

% TIME 
ON 

MISSION AVERAGE 
BIT RATE Mb/S 

GIVEN 

MODI 

M0D2 

GIVEN 

MODI 

M0D2 

A 

10-30 

1-2 

20 

20 

20 

2.5-5 

1.0 

2.0 

2.0 

B 

1-10 

1-4 

5 

5 

4.5 

2.5-10 

.5 

2.0 

1.8 

C 

'1-1 

4 

.5 

.5 

0.55 

100 

2.0 


2.2 * 

D 

1-1 

8 



0.55 

50 



2.2 

E 

.01-. 1 

10 

.04 

.04 

0.06 

100 

.4 

B 

0.6 

F 

.01 

20 

.005 

.005 

0.01 

100 

.1 

D 

0.2 


TOTALS 4.0 8.5 9.00 



It is instructive now to assume that the mission average can be applied 
to a per orbit scenario and to discuss what percentage of total data the high- 
rate data can be per orbit. 

We know that the orbit is a 100 minute orbit, with 70 - 80% of real-time 
contact and 20 - 30% of black time when the high-rate data can be played back 
for early missions only. 

Now the average high-rate playback rate of A & B combined is 1.5 Mb/s, 
and we will use 20% of the orbit as a worst case black time. This is 20 minutes. 
Therefore, the number of bits which can be played back is: 

q 

20 minutes x 60 secs/min x (1.5 x 10 ) bits/sec = 1.8 x 10 y bits 

i 

And for the remaining 80 minutes, the average rate is 4.8 Mb/s. Therefore, the 
number of bits of real-time low-rate data is: 

80 minutes x 60 secs/min x (4.8 x 10®) b/s = 23.04 x 10^ bits plus 
normal high-rate data 


Therefore, the percentage of data/orbit which is high-rate data, that 
can be made available is: 


( 1.8 

23.04 + 1.8 


x 100 = 


7 246% 


Now it is shown elsewhere in this study that on the average, there will 
be a burst of high-rate data once per orbit, and that this represents 5.21% 
of the total data. , 

Therefore, because 5.21 < 7.246 it is shown that scenario number 
3 can be accommodated with a high-rate slow down of 2.5:1 and low-rate real-time 
acquisition. 
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INPUT DATA 


5 3 

We will now compute an approximation of the typical experiment data 

file. This can be obtained from the previously given information as tabulated in 

Table 5-1. Summing the BIT RATES in the last column of Table 2-1, an average 

mission bit rate of 4 Mb/s is confirmed. Thus, group A experiments would consume 

% of the total bit volume. Group B experiments would likewise consume 0.5/4 

of the total bit volume. These values are tabulated in the second column of 

Table 5-2 under % OF MISSION AVERAGE BIT RATE. Since a total of 5 x 10 12 bits 

are collected per mission, applying the computed percentages, the NO. OF BITS 

PER MISSION FOR THE EXPERIMENT GROUP is then derived (i.e , 25% of 5 x 10 12 = 1.25 

x 10 for group A experiments). Dividing the number of bits per experiment 

group by the number of experiments, yields the NO. OF BITS or BYTES PER EXPERIMENT 

as shown in Table 5-2. It should be pointed out that the computed groups C and 

D consist of 4 full-or 8 part-time experiments and are equivalent in volume to 

8 full-time experiments. Thus, each full-time experiment equals (approximately) 

9 9 

313 x 10 bits or 39 x 10 bytes. A half-time experiment is assumed to be half 
of the volume of a full-time experiment. To visualize the relative volumes of 
experiment data, Figure 5-4 is offered. 
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Sum: 


TABLE 5-2 

A HYPOTHETICAL MIX OF EXPERIMENT DATA 
FOR A 7-DAY MISSION 


NO. OF 
EXPERIMENTS 
& (Exp. Group 
Designator ) 

% OF MISSION 
AVERAGE BIT 
RATE 
(*) 

NO. OF BITS 
PER MISSION 
FOR EXP. GROUP 

(xlO 12 ) 

NO. OF BITS 
PER EXP. 

(xlO 9 ) 

NO. OF BYTES 
PER EXP. 

(xlO 9 ) 

2 (A) 

25.0 

1.25 

625 

78 

4 (B) 

12.5 

0.625 

156 

20 

4 (C) 

j 50.0 

} 2.50 

313 

39 

8 (D) 

( 

156 

20 

10 (E) 

10. 

0.50 

50 

6 

20 (F) 

2.5 

0.125 

6 

1 

48 

100.0 

5.00 
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NORMALIZED VOLUME 






Since the average data rate for low-and medium-data rate experiments 
(Ry^) is assumed for the purposes of this analysis to be between 4 and 8 Mb/s, 
the instantaneous average data rate for low-and medium-rate experiments (R^) 
can be (arbitrarily) defined as: 

R LM = + 4f(t)) Mb/s and 

= 6 Mb/s. 


where’ 

Y m = average data rate for low-& medium-data rate experiments 

= instantaneous data rate for low-& medium-data rate experiments 

f(t) = a random walk function that has its mean value and sigma 
defined as: 

m=2 

(5s=2) 

s=.4 

12 

Since the total data volume (D-j.) equals 5 x 10 bit/mission, let' 

Dy = D lm + = 5 x 10 12 bits/mission 

where: 

= data volume due to the average steady state data rate R^ 

= data volume due to high rate experiment data rate R^ 
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can be computed to be. 




day 


mission 


x 24 By x 3600 


^fr- X (6xl0 6 ) 


bits 

sec. 



3.63 x TO 12 


bits/mission 


Therefore can be computed by: 


°H ~ D T “ y 

D h = (5-3.63) x TO 12 bits/mission 
= 1.37 x TO' 1 ' 2 bits/mission 

The average data rate associated with the high-rate experiments 
R h can be derived from the following expression: 



where: 

R-j. = highest SDPF input data rate 
f^= average low and medium data rate contribution 
Since: 

R^. = 50 Mb/s and 

6 Mb/s 

Then: 

T h = 50-6 = 44Mb/ s 
Since: 

R-j. = 50 Mb/s and 

f^ M = (4+4f(t)) Mb/s 


Then the instanteous data rate for the high rate experiments (R u ) 

n 

is defined by: 


R H “ R T " R LM 
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R h = 50— ( 4+4f (T) ) Mb/s 


R h = 46 - 4f(t) Mb/s 

Therefore. 

Rjj' = 44 Mb/s 

Since: 

Rr = Ry^j + 44+6 - 50 Mb/s + 

The next task is to compute the contribution of the high-rate 
data experiments to the total data volume. Since - 44 Mb/s and 
D^ = 1.37 x 10 12 bits/mission, then the total time on (T^) would be 
derived from the expression* 

t h = d h ' ¥ 

12 

7 _ 1.37 x 10 bits/mission 
H 44 x 10 6 bits/sec 

Tj_j = 8.65 hours/mission 

This amount of time, it should be noted, represents 5.21% 

(8.65 /(7x24)) of the total mission time. This estimate checks with 
earlier estimates in the study. 

Because the 50 Mb/s data is captured in the DCS and the SOPS is sized 
to handle 4-8 Mb/s, a slow down of 4/50 or 8/50 could solve the processing 
problem. As high-rate data slows, so the processing time is correspondingly 
multiplied. The high-rate data represents approximately 8.65 hours of real-time. 
Slowing down the data to 4-8 Mb/s would therefore mean the total time to process 
this data (excluding physical stop, starts, mounting, etc.) would be (50/4) x 
8.65 108.13 or (50/8) x 8.65 54.06 hours. This represents 4.51 or 2.25 

twenty-four hour days of continuous data processing. 
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5.4 


OUTPUT DATA PRODUCTS 


This section shall describe some general computations on the nature of 

the output products generated by the SOPS. Four output media are envisioned 

(1600 bpi , 6250 bpi, HDT, 56 Kb/s transmission line), their salient characteristics 

(bit capacity per reel and data transfer rates to create such produces) are 

tabulated in Tables 5-3 and 5-4. A useful computation is the number of reels 

of .magnetic tape that would be required to hold the entire mission data base 
12 

(5 x 10 bits). These values are shown in the fourth column of Table 5-3. 

Based on the given two-volume mix earlier stated (Section 2. 1.1. 2), 
two-volume mixes are tabulated m columns 5 and 6 of Table 5-3. It will be 
assumed for the sake of simplicity that these volumes support the indicated 
number of experiments and that the minimum number of reels to contain this data 
is at least as shown in columns 7 and 8 (Table 5-3). Table 5-5 provides a cross 
reference to how many reels of 1600 bpi, 6250 bpi, HDT, or how many seconds on a 
56 Kb/s line would be required to handle one experiment. 

At this time, it is not known precisely how most of these output 
products would be distributed, but one can tabulate the distribution as shown 
in Table 5-6. Only the two "A" group experiments are known to be transcribed 
onto HDT. 

The foregoing accounts only for experiment data, we must also add 
attitude and ephemeris data. (Section 5.3.3 projects about four 1600 bpi reels 

or one 6250 bpi reel for one complete set). 


0 
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( TABLE 5-3' 


TWO-VOLUME DISTRIBUTIONS 

I 2 3 4 5 6 7 8 



Media 

Bit 

Capacity 



Data XPer 
Rate in 
bits/s. 

No. of Reels 
to hold 

5xl0 12 bits 

Vol . 1 

in 10 12 
Bits 

Vol. 2 

in 10 12 
Bits 

Minimum No. 
of Reels of 
Tape for 
Vol. 1* 

Minimum No. 
of Reels of 
Tape for 
Vol. 2* 

MEDIA. 

1600 bpi 

3 x 10 8 

2.0 M 

16,667 

2.5 

0.5 

8334 

1667 

6520 bpi 

1.2 x 10 9 

10. OM 

4,167 

1.0 

1.25 

834 

1041 

HDT 

1.4 x 10 10 

0. 5-*20. 0 M 

357 

0.5 

0.75 

35. 

53 

Comm. Lines 

N.A. 

56 K 

N.A. 

1.0 

2.5 

Hours of Coirnn 
Time over 1 
line for Vol.l 

Hours of Comm. 
Time over 1 
line for Vol. 2 

5556 

13,889 




Sum = 5 x 10 12 bits 



*Note: These values are "minimum, i.e., packed experiment data. 















TABLE 5-4 


COMPARISON OF MAGNETIC TAPE SPECIFICATIONS 


Characteristics 

High Density 

Computer-Compatible Tape 

Digital Tape 

1600 bpi* 

6250 bpi** 

Nominal Length 
(meters ) 

< 2195 

732 

732 

(feet) 

< 7 2t)0 

2400 

2400 

Data Capacity 
(bits/reel ) 

10 

1.4 x 10 xu 

3 x 10 8 

1.2 x 10 9 

Data Transfer Rates 
(megabits/second) 

0.5 - 20 

2 

10 

Error Rates 
(bits) 

1/10 6 

1/10 9 

1/10 9 


*At 125 inches per second; 3600 bytes per block (80% packing efficiency). 

**At 200 inches per second; 7500 bytes per block (80% packing efficiency). 
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TABLE 5-5 

ESTIMATED EXPERIMENT VERSUS MEDIA CROSS REFERENCE 


Experiment 
_ Group 
Designator 

No. of 
Bi ts/Exp. 

(xlO 9 ) 

No. of Reels of Tape 
To Hold 1 Experiment 

No. of Sec. of 
Com. _Time_on 
One 56 Kbps 
Line to 
Transmit One 
Experiment 

1600 bpi 

6400 bpi 

HDT 

A 

625 

2083.3 

520.8 

44.6 

1.12 x 10 7 

B 

156 

520.0 

130.0 

11.1 

2.79 x 10 6 

C 

313 

1043.3 

260.8 

22.4 

5.59 x 10 6 

D 

156 

520.0 

130.0 

11.1 

2.79 x 10 6 






■■ 

E 

50 

166.7 

41.7 

3. 6 

1 

F 

6 

20.0 

5.0 

0.4 

1.07 x lO 5 
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TABLE 5-6 


POSSIBLE DISTRIBUTION 
OF OUTPUT PRODUCTS 


Experiment 

Group 

Designator 

No. of 
Bits/ Exp. 

(xlO 9 ) 

Total 
No. of 
Exps. in 
. Grt)up 

Possible Distribution 
Of Output Products. 

1600 bpi 

, 6250 bpi 

HDT 

nm 

A 

625 

2 

0 

0 

2 

0 

B 

156 

4 

0 

i 

3 

0 

C 

- 313 

4 

0 

k 

1 

0 

D 

156 

8 

0 

m 

n 

0 

E 

50 

10 

P 

q 

0 ' 

r 

F 

6 

20 

s 

t 

0 

u 









Notes: i + j - 4 

k + I = 4 

m + rt = 8 

p + q + r - 10 

s + t + u ~ 20 
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5.4.1 Tape Products 


It would be worthwhile at this point to compute the approximate number 
of tape recorders to output the required data volume. One can start this 
computation by defining the number of reels (n r ) to contain the projected volume 
as* 

n r ■ II (1) 

V R 

where n r = number of reels of tape per mission 

Vy = total volume of data on tape in bits per mission 
V R = volume of data on a reel in bits per reel 


Using the linear expression D= RT (distance = rate x time) and the 
fact that D also equals the product of n r times the length (L) of a reel, the 
time (T) in seconds to record (at R rec ips) and rewind (at R ^) ips) on a 
single tape recorder would be: 


T = J3 + 
R 

rec 



p P 

rec + rwd 

p P 

rec * rwd 


( 2 ) 


T = L • 



P 0 

rec + * rwd 
n rs 

rec * rwd 


( 3 ) 


where 

T = time in seconds 
L = length of a reel in inches 
n r = number of reels 

= Record speed in inches per second 
R rwd = Rewin d s P eed m inches per second 

Since 1600 and 6250 bpi tapes are recorded and rewound at the same speeds, it 
is legitimate to combine the number of reels of 1600 and 6250 bpi . At this 
Point, in a preceding table (Table 5-5.), it was stated that 2 volumes are 
projected. It was also computed that for the first volume, (8334 + 834) 9168 
and (1667 + 1041) 2708 reels could be produced in the facility. This represents 
the projected CCT tape volume only. To see what time would be consumed on only 
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one (1) transport for these 9168 and 2708 reels, let: 


L = 2400' = 2400 * 12" 
n r = 9168 or 2708 

R rec * 200 lRS 
R rwd * 640 1RS 

Then for a continuous record and rewind on ONE tape transport with no 
mount or demount considerations for 9168 reels- 


T ~ 2400 


12*9168 (640 + 200) ~ 173 x 1Q 6 


640 > 


200 


seconds 


~ 1-73 x 10 sec cr /ipi 
" 3600 sec 
hr 


hours 


~ 481 hr 
“ 24 hr 
day 


=20.1 days 


For 2708 reels: 


■r ^ 2400 » 12.2708 (640 + 200) 
1 640 - • 200 

T - pcnn Lf- 6 - 1 -- = 142 hours 
3600 sec 

hr 

T “ MTr7" 5 * 9 dayS 

dly 


= 0.51 x 10 u seconds 


From the above, it is obvious that multiple transports will be required. 
With multiple units, the time lost due to rewinding disappears since a rewind 
will take place during write operation. 
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The task at hand is to determine how many tape transports would be 
required to handle the programmed volume. To compute the number of tape drives 
and operators required -for a~7-day- mission 


Write time per tape 


Rewind time per tape 


Allow 3 min for search 
and mount 


Total tape handling time 
per tape 


2400 feet x 12 secs 
200 ips 

144 secs = 0.04 hrs 

0.75 min = 0.012 hrs 

0.05 hrs 

0.04 + 0.012 + 0.05 hrs 


= 0.102 hrs. 


No of tapes that can be handled in one day 

* 24 hrs = 235.29 tapes 

0.102 mins/tape 

For a seven-day operation, the number of tapes/day for each of the volumes 
previously calculated is 1310 and 386.86. 

number of drives for each volume is 


1310 and 386.86 
235729 235.29 

= 5.57 and 1.64 

6 2 

showing that we require one (1) operator per tape drive, allowing a net time 
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between mounts of 0.0025 hrs or 9 secs. But with 2 operators to attend a tape 
drive, each would have 0.052 hrs (3.15 mins rest) with three operators per tape 
drive 0.104 (6.30 mins), etc. Therefore the number of operators required to 
handle tapes is entirely a function of real time. 

Consider having 12 drives for volume #1 

Then time to mount - 

= 12 x 0.05 
s 0.600 hrs 

and time to run - 

= 12 x 0.052 
= 0.624 hrs 

giving a rest time 

= 0.024 hrs 
= 1.44 mins 

Performing this for 24 drives gives a rest time of 2.88 mins. 

Thus, in this case the trade-off for similar rest times is the number 
of tape drives versus the number of operators. 

Note that in order to obtain about a 3 min average rest time we had 
to either double the number of operations (in 6 drive case,from 6 to 12), or 
quadruple the number of drives (from 6 to 24). 

Consider using the cal comp ATL system, which has a 15 sec retrieve and 
mount time, i.e., 30 sec total tape handling time we have - 

30 secs = 0.0083 hrs 

Now, total tape time = 0.04 + 0.012 + 0.008 

= 0.06 hrs 

Number of tapes which can be handled in one day = 400 
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No. of drives = 1316 
400 


and 


386.86 

400 


= 3.724 = 0.967 

Or 4 Or 1 

If we consider 25% down time, we get - 

5 and 2 

The cost of the ATL can now be traded off against the cost of operations. 
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5.4.2 Communications 

As can be seen from Table 5-5, a number of experiment file groups 
are candidates for telecommunication transmission in lieu of tapes. These are 
groups F, E, D, B, and C. Assuming one line to each experimenter, what are 
the possibilities (in terms of time) 7 Table 5-7 provides a quick reference to 
how many seconds are in each full 7-day work week by 1, 2, and 3 full shifts. 
Table 5-8 provides a cross matrix of the possibilities. As can be seen in the 
table, only selected experiments groups E and F can be serviced. 
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TABLE 5-7 

MAXIMUM NUMBER OF SECONDS IN WORK WEEKS 


WEEKS 

SHIFTS* 

PER 

DAY 

TOTAL TIME 
IN 

SECONDS 


3 

6.05 x 10 5 

1 

2 

4.03 x 10 5 


1 

2.02 x 10 5 


3 

1.21 x 10 6 

2 

2 

8.06 x 10 5 


1 

4.03 x 10 5 

• 

3 

1.81 x 10 6 

3 

2 

1.21 x 10 6 


1 

6.05 x 10 5 

• 

3 

2.42 x 10 6 

4 

2 

1.61 x 10 6 



8.06 x 10 5 




* 8 hours continuous time per shift 
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TABLlf’S-B 


POSSIBLE EXPERIMENT COMMUNICATION COMBINATIONS 


1 

No. of 
Exps. in 
Group 

No. of Sec. 
to Xmit. 

1 Exp. 

File on 1 56 
Kb/s Line 

3S 

Iw 

2S 

IS 

3S 

1-4 w 

2w 

2S 

aeks 0 
IS 

1-3 shi 
3S 

ft/day 

3w 

2S 

IS 

3S 

4w 

2S 

IS 

A 

2 

1.12 x 10 7 

N 

■ 

B 

N 

N 

N 

N 

B 

N 

N 

. 

B 

N 

B 

4 

2.79 x 10 6 

N 

n 

N 

B 

N 

B 

N 

B 

N 

N 

B 

N 

C 

5 

5.59 x 10 6 

N 

D 

B 

N 

g 


N 

B 

B 

N 



B 

N 

D 

8 

2.79 x 10 6 

N 

B 

N 

B 

B 

N 

N 

B 

N 

B 

a 

D 

E 

10 

8.93 x 10 5 

N 

B 

N 


B 

N 

■ 

H 

N 


B 

N 

F 

20 

1.07 x 10 5 

Y 

(5.65) 

Y 

(3.77) 

Y 

(1.89) 

Y 

(11.3) 

Y 

(7.53) 

Y 

(3.77) 

Y 

(16.9) 

Y 

(11.3) 

Y 

(5.65) 

Y 

(22.6) 

Y 

(15.0) 

Y 

(7.53 


N = NO 
Y = YES 

( ) = LINE UTILIZATION TOTAL TIME IN SEC. DIVIDED BY ONE FILE SIZE 


900 




































































5.4.3 Ephemeris & Attitude Data 

Generally stated, the volume (v) of ephemeris and ancillary data that 
will be computed and subsequently written into CCTs are* 


V = D days 

mission * 


24 hours x 
day 


3600 sec , x B bytes data 
hr. S sec. 


or 


V ~ ° x 8.64 x 10 4 bytes data 

mission 


where 

D = No. of days for mission 
B = No. of bytes per data point 
S = No. of seconds per data point 

Based on previous data in Section 2, D-7, B=400, and S=2. 

Therefore 


V = 7*400 
2 


x 8.64 x 10 4 bytes 
mission 


V = 1.21 x 10 8 bytes 

mission 


It shall be noted that this volume of data is projected to be recorded 
on 1600 or 6250 bpi tape for each experimenter. A typical reel of 1600 bpi 
tape holds about (3/8) 0.38 x 10 8 bytes and a reel of 6250 bpi tape holds 
(12/8) 1.5 x 10 8 bytes. Thus, about (1.21/. 38) 3,18 reels of 1600 bpi tape or 
(1.21/1.5) 0.81 reels of 6250 bpi tape would be required to hold the volume of 
data. It is envisioned that each experimenter will get one 1600 bpi 9-track 
tape per day per experiment. 
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6.0 


ALTERNATE ARCHITECTURES 


In order to arrive at a set of potentially feasible architectures which 
will satisfy the mandatory requirements of the SOPS, the alternate flows of data 
within the system must first be considered. The major functions in the system 
are to decommutate experiment data, to archive it, and to present experimenters 
with orderly and complete information. The following sections examine two pos- 
sible data flows which accomplish these. Each data flows positions the decom- 
mutation function and the Mass Storage System (Mss) differently. The high- 

level data flows are shown in Figures 6-1 and 6-2 respectively. 

/■ 

6.1 DATA FLOWS 

In Figure 6-1, the data flow shows that the work units are assembled 
and keyed to the (DCS) data lines rather than to the experiments. The opera- 
tions performed on the data are executed after storing the data into the MSS. 

In Figure 6-2, the data flow indicates that the decommutation function 
is performed in the front end of the system and the data is subsequently assem- 
bled into work units which by definition are unique for each experiment. Thus, 
the data stored in the MSS would be in a format related to experiments (as 
shown in Figure 6-3 under DECOMMUTATED DATA), and would be ready for further data 
operations and formatting into output experiment data files. 

It can be readily seen that these two flows exhibit a difference not 
only in the formats of the files in the MSS, but also in the allocation of 
time in the performance of work on the data itself. 

Table 6-1 shows that either of these data flows and their subsequent 
implementations satisfy all of the mandatory requirements outlined in Section 
2 of this study. From these data flows, it was possible to derive two archi- 
tectural families which will perform the required functions. Each architecture 
will be analyzed in terms of each data flow. 
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LOGIC OPERATION 


COMMENTS 


1 


2 


3 


4 


5 


6 


7 


S 


9 


10 


11 



ACCEPT ALL DATA RATES 


ASSEMBLE CONVENIENTLY LARGE WORK UNITS (MAYBE IN 
UNITS COMPATIBLE WITH THE MASS STORAGE SYSTEM) 


STORE COMMUTATED DATA ON A DATA LINE BASIS 
(CORRESPONDING TO DATA LINES FROM THE SIPS) 
IN MSS 


PERFORM TIME VALIDATION, OVERLAP REMOVAL, GENERATE 
FILL, ETC 


SEGREGATE ANCILLARY DATA IN EITHER LOCAL STORE OR 
MSS FOR EASE OF DATA FLOW 


REFORMAT ORBIT AND ATTITUDE DATA AND PERFORM 
COORDINATE TRANSFORMATIONS, OUTPUT O/A TAPES 


DECOMMUTATE "j" EXPERIMENTS FROM "k" INPUT LINE 
FILES AGAINST A KNOWN MAP 


WHEN REQUIRED, MERGE ANCILLARY DATA WITH EXPERIMENT 
DATA 


WRITE TAPES, SETUP COMMUNICATIONS, ETC 


NOTE 

PERFORM ACCOUNTING AND QUALITY CHECK FUNCTIONS 
AT EACH STEP 


FIGURE 6-1 DATA FLOW NUMBER 1 
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LOGIC OPERATION 


COMMENTS 



ACCEPT ALL DATA RATES 


PERFORM TIME VALIDATION, OVERLAP REMOVAL, 
GENERATE FILL, ETC. 


DECOMMUTATE "j" EXPERIMENTS FROM "k" INPUT LINES 
AGAINST A KNOWN MAP MAY BE DONE IN EITHER HARD- 
WARE OR SOFTWARE ENVIRONMENT 


SEGREGATE ANCILLARY DATA IN EITHER LOCAL STORE OR 
ON MSS FOR EASE OF DATA FLOW. 


ASSEMBLE CONVENIENTLY LARGE WORK UNITS {MAY BE IN 
UNITS COMPATIBLE WITH THE MASS STORAGE SYSTEM (MSS) 


HAVE THE MSS PREDEFINED FOR EXPERIMENT FILE ALLOCA- 
TION (THIS IS DONE WITH THE EXPERIMENT MAP) 


REFORMAT ORBIT AND ATTITUDE DATA AND PERFORM 
COORDINATE TRANSFORMATIONS, OUTPUT O/ATAPES “ 


WHEN REQUIRED, MERGE ANCILLARY DA-TA-WITH EXPERI- 
MENT DATA 


OVERLAP REMOVAL, (GENERATE FILL IF REQUIRED), 
GENERATE TAPES AND SET UP COMMUNICATIONS 


NOTE 

*PERFORM ACCOUNTING AND QUALITY CHECK FUNCTIONS 
AT EACH STEP 


FIGURE 6-2 DATA FLOW NUMBER 2 
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DECOMMUTATED DATA 


COMMUTATED DATA 


E 1,1' E 1,2' E 1,3 


L i,i' h,2' h,3' 

E 1,n' E 2,1 


- - - - 

E 2,2’ E 2,3 


"* *" 17 d' *"2,1 ' 

E 2,m' E 3,1 



E 3,y' 


• * L 2,e' L 3,V L 3,2' " 

E 4,1' 


- 

* • * E M,z 


L 18,g 


EXPERIMENT DATA (E) IS STORED SEQUEN- 
TIALLY BY THE FOLLOWING INDICES 

Experiment no , data element no 


LINE DATA (L) IS STORED SEQUENTIALLY BY 
THE FOLLOWING INDICES __ 

L DCS LINE NO , DATA ELEMENTNO' 

TO CONSTRUCT AN EXPERIMENT DATA FILE, 
A ONE-TO-ONE MAPPING OF THE ABOVE LINE 
DATA SHALL BE PERFORMED^ 


FIGURE 6-3. SIMPLIFIED ILLUSTRATION OF DATA 

ELEMENTS IN THE MASS STORAGE SYSTEM 
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TABLE 6-1 


A CROSS REFERENCE TO THE FUNCTIONAL 
REQUIREMENTS/SPECIFICATIONS IN CANDIDATE ARCHITECTURES - 


STEP 

NUMBER 

ARCHITECTURE 
NUMBER 1 

ARCHITECTURE- 
NUMBER 2 

3 

2. 1.2.1, 2. 1.2. 3. 

2. 1.2. 6 

4, 

2. 1.2. 5 

2. 1.2.4 

5 

2. 1.2. 6 

2. 1.2. 9 

_6 

2. 1.2. 9 

2. 1.2.1; 2.-1-.2-.3-- ' 

_7 

2. 1.2. 7; 2.1. .8 

2. 1.2. 5 

8 

2. 1.2. 4 

2. 1.2. 7; 2. 1.2. 8 

9 

2.1 .2.9 

2. 1.2. 9 

10 

2.1.4; 2,1.5, 2. 1.2. 3; 

2.1.6, 2.1.7, 2. 1.2. 3, 


2. 1.2. 2 

2. 1.2. 2 

- 
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The following alphabetic notations shall apply uniformly in the dis- 
cussions of the proposed systems: 

A = Number of identical incoming Work Assembler (WA) subunits 

B = " " bytes of buffer in each WA buffer 

C = 11 " buffers in each WA 

D = " " Buffer Analayzers (BA) 

E = (not used) 

F = (not used) 

G = Number of Mass Storage Units (MSU) 

H = " 11 bytes of storage in each MSU 

I = (not used) 

J = (not used) 

K = Number of identical Computational Subsystems (CS) 

L = “ " Memories in CS 

M = 11 11 bytes of storage in each CS memory 

0 = (not used) 

P = Number of 1600 bpi tape transports 
Q = Number of 6250 bpi tape transports 
R = “ " HDT transports 

S — " “ Commumcation modems 

T = Number of Staging Disks (SD) 

U = Number of bytes of storage per ( SD ) 

V - (not used) 

W = (not used) 

X = (not used) 

Y = (not used) 

Z = (not used) 
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6.2 ARCHITECTURE NUMBER 1 

Architecture number 1 is illustrated in Figure 6-4. This architecture 
fully supports data flow number 1 (as previously illustrated m Figure 6-1). 

A brief system utilization walkthrough is presented below. 

Spacelab and GMT data enter the system via multiple SIPS output lines. 

It is assumed that all data on these lines are commutated (viz. lines 1 through 
18). The data enters a Work Assembler ~(W A) ~ whe re - co nveni ently la rg e" buffer s are 
built. When the appropriate Mass Storage Unit is available, a large buffer 
load of data is written out. This process continues in time to roughly 
correspond to one orbit (approximately 100 minutes). During this interval 
precise [information concerning the layout of experimenter data is collected 
and sent to the Resource Monitor (RM)'.~~This data" col lec tio n" and "temporary buffer-, 
mg of data continues in units of "orbits" until the end of the mission. 

At some chosen point in time corr esp onding to e~ither_the 2nd dr 3rd 

orbit), the output processing of data begins. The output subsystems receive 
scheduling information from the Resource Monitor for editing the data, extract- 
ing the ancillary data necessary for each experiment, reformatting and output- 
ting ephemens and attitude data, decommutating the data base, merging ancillary 
data, and final format! ng/outputting of data products. Peripherals, as re- 
quired, are selected from a pool (as shown in detail in Figure 645) and are 
assigned to any of the "K" suosystems (as shown m Figure 646 }. 
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FIGURE 6-4. ARCHITECTURE NO. 1. 


(DYNAMIC CONFIGURATION) 








6.2.1 Work Assembler 

The first major assembly of equipment is the Work Assembler (WA) , 
which is illustrated in Figure 6-7. As shown, it has 19 primary inputs - 
18 data input lines (a one-to-one correspondence with the 18 SIPS output lines), 
and one (1) GMT line from the SIPS. Associated with each SIPS data input line 
is an interrupt line which notifies the WA of incomplete data frames, error- - 
situations, end of data frames, etc. 

The major function of the WA is to smooth the incoming data stream 
so that data can be subsequently transferred to the Mass Storage System (MSS). 

As part of this function, the WA also dispatches larger groups of data to the 
MSS at a (MSS) compatible data rate. This is illustrated in Figure 6-8. At 
the top of Figure 6-8 the 18 input lines are shown in time so that one can 
see the 16 bit data words entering the system. This upper time slice illu- 
strates the fact that input data are not necessarily periodic. However, 
as the WA collects data, it will transmit the data to subsequent portions of 
the system when larger groupings are advantageous (this is shown in the 
middle portion of the figure ). If one were to merge the individual WA out- 
puts, they would appear as illustrated at the bottom of Figure 6-8. 

In Figure 6-7, an individual WAconsistsof C buffers and an associat- 
ed Buffer Analyzer (BA, which may be either a dedicated CPU dedicated micror 

processor or a shared CPU). Each WA subunit should be identical so that any 
system reconfiguration can take place with the [east number of problems. 

The BAS receives data from the SIPS and transmits it to the Resource Monitor. This 
data exchange consists of "data maps", quality information, error~me'Ssages , 
etc. — - — 

Since quantities have to be estimated in order to size the entire 
WA system, let: 

A = The number of identical incoming WA subunits 

B = The number of bytes in each WA buffer 

C = The number of buffers in each WA subunit 

D = The number of Buffer Analyzers (BA) 

Based on given materials, it appears that A has to be set to at least 
18. One cannot assume that certain lines are going to be inactive during 
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FIGURE 6-5. SUBSYSTEMS AND UNASSIGNED PERIPHERAL POOL 











RESOURCE 

MONITOR 

(RM) 

\ r • t 

1" "2" "K" 

SUBSYSTEM "1" 



SUBSYSTEM " 2 " 






\ 

I 

> 





i I 

■FIGURE 6-6. HARDWARE^ SYSTEM NO. 


1 


DETAIL (ASSIGNED CONFIGURATION) 






WORK ASSEMBLER #1 



FIGURE 6-7. GENERAL BLOCK DIAGRAM FOR WORK ASSEMBLER SUBUNITS 









SIPS INPUT 
DATA LINES 


16 — ►) h — 



FIGURE 6-8. TIMING DIAGRAM OF WORK AS? 
AND OUTPUTS 



L5 


B BYTES 



INPUTS 


an orbit at this point in time. Operational modes may change, and the system 
must be capable of supporting the full SIPS output. The number of WA sub- 
units (A) should have either 1 spare unit or 5 to 10% spares as a good back- 
up. Thus, either 1, .9, or 1.8 units could be designated for spares. 

System or Device Utilization 

The question that arises at this point is: "What analytical ex- 

pression is used to determine the capacity of a device to perform a known 
unit of work? ". For example, a 1000 byte buffer that is only used to hold 
500 bytes is intuitively said to be operating at 50% capacity. This capacity 
or utilization is simply the ratio of the work load divided by the maximum 
resources available. For a computational system, one can apply the same 
basic concept, i.e., divide the number of operations to be performed by the 
maximum capability of the device to perform those operations. This approach 
can be seen in the following examples. 

Suppose that a computer were to be required to perform only load and 
store operations on a closed data set. In a unit period of time (say one second) 
the work load to be performed would be 10 operations. Suppose that the device 
performing this work would be capable of operating at 10^ operations per second. 

C -I 

~The- expression (10 * 10 ) x 100 would yield the information that the device is 
-operating at only 10% of its full capacity. 

The preceding is an example of an uncomplicated situation. Suppose 

C 

that for the same work load (10 operations per second) the machine were only 
capable of performing 10 operations per second. The quotient then would indi- 
cate a 100% utilization. The question then is: "Does one rely on that single 
device to perform that work?" The answer would be yes if, and only if, no 
deviations were allowed in both load and device capability. But suppose 
that a small number of other operations were to be present but not included 
in the computation. Then at least two devices would be required to perform 
that work load. 

Going one step further, suppose that a mix of operations were to be 
performed over a unit period of time and the quotient indicated that the util- 
ization factor would be, for example, equal to 560%. First, the 560% asserts 
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that 5.6 devices working in parallel are required. Does one round up to 6 
devices or some other number between 6 and 12 ? No general rule answers this 
question; any answer has to be qualified as with all given and assumed data. 

It has been found (among a representative number of computer facility managers) 
that for scientific applications, at a 40 to 50% utilization, one device is 
chosen. Between 50 to 100% two devices are usually used, because transient 
changes in the work load, interrupts, and initiations usually consume the last 
50% of a machine's capacity. 

For purposes of this short discussion, assume that the system should 
support an input data rate of 8 Mb/s. For purposes of this analysis, let the 
minor frame size be set to 4096 bits. Thus, the number of minor frames per 
second is (8 x 10 6 bits/sec)/(4096 bits/minor frame). This product is 1953 
minor frames per sec. Also, assume that there are 100 frames per major frame. 

Thus, 195 3 major frames per second will also have to be processed by the WA. 

Using the software estimates previously seen in Table 4-11, the BA 
will perform approximately 100 operations (lines of code executed) on each minor 
frame (input data accounting and quality checking) and approximately 200 operations 
on each major frame. Thus, taking the products of the number of minor frames per 
second (and major frames per second) times the number of operations per frame, we 
have a total of: 

{1953 — x 200 + (1953 — x 200 ^2- ) ~ 2 34 x 10^ °P era 'bl°ns 

u J sec x 1UU mf sec x iUU MR ' x iU second 

The work load to perform the functions in the WA as a whole is approximately 
2.34 x 10 operations per second (or 4.27 x 10 seconds per operation). A 
typical minicomputer as profiled in Table 4-7 was shown earlier to be capable 
of performing at a rate of 0.7 ps per cycle (or 1.43 x IQ 6 operations per second). 
Since the operations to be performed are of the Load/Store type, one should 
multiply the cycle time by a factor of about 3 to make the cycle time effective. 
Thus, the number of operations per second for the minicomputer is (3 x .7us)**^ 
which is 4.76 x 10 5 operations per second. 

To formalize the above concept, it would be helpful to express analytically 
the ratio of work to be done versus system capability, as "u". Thus, one of the 
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tools to determine the acceptability of the candidate computation unit is a deter- 
mination of the system utilization (u) factor. The relationship can be expressed 
as: 


u 



x 100 


f X c 


Where: 


And: 

Where: 


u - computer utilization (%) 
r.j= input data in Mb/s. 
s m f= Size of a minor frame in bits 
s M p= Size of a major frame in bits 

j = total number of lines of code executed for each 
minor frame of data 


k = total numbev of lines of code executed for each 
major frame of data 

f = multiplicative factor (to convert cycle time to 
instruction time) 

c = cycle time in seconds of candidate CPU 

S MF = n ( s mf) 

/ 

n = integer number of minor frames per major frame 


For ease of data manipulation, the expression for u reduces to: 


u - 


100-c>f*r. 

— V 



Since the nature of the input data stream is not narrowly defined as 
yet, it would be advisable to examine u with different factors being varied. 

The above compact expression is obviously very sensitive to certain combinations 
of driving factors. The objective is to determine the worst case which drives 
up the system utilization. The factors that are relatively fixed are "c" at .7 
us (from the minicomputer characterization section), "f" at 3 (to very closely 
approximate load and store operations), "j“ at 100 (best known approximation), 
and "k" at 200 (best known approximation). 
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The expression for "u" can be simplified (just for the previous 
case) to: 


■v-6 


u = (1°°) (-M0 ") (3)(r t ) (100 + m . 2-1 x 10 


-2 


mf 


r <Hr> 

s mf n 


Before searching for the worst case, u should be evaluated to establish 
a baseline ooerating point. 


Typical values are as follows* 

s - * 4096, 2048, 1024, 512 bits 
mf 

r. = 8, 12, 20 Mb/s 

i 

n = 100, 50, 10 

Table 6-2 provides a range of values for "u" as a function of s^, t* 1 , 

i - 

and n. 

As can be seen from Table 6-2, as the input data rate goes up, so 
the number of processors to handle the work goes up, and as the buffer size 
(the minor frame size) goes up, so the amount of work to be done goes down. 
Additionally, the number of minor frames to a major frame has relatively little 
effect on changing the magnitude of utilization factor, (i.e., it takes the 
form of 1/n). Table 6-2 is presented graphically in Figure 6-9. 

The next step is to determine the size of the buffers in each WA 
subunit. As will be seen in the next section, it will be wise to set the buffer 
bize to some value between 10 and 13K bytes. This range of buffer size will 
permit the WA to interface easily with either disks, MSS' (like the Terabit), 
or HOT. As shown earlier, disks operate efficiently when data is sent to-them • 
in units as close to a data track. (The Terabit system uses disks to stage data 
onto and off of its magnetic tape. Additionally, the Terabit system's best unit 
of data transfer to magnetic tape is ten times a 3330 data track). 

To summarize, the WA can be defined in terms of hardware and capital 
expenditure as shown in Table 6-3. Using the information in Tables 6-2 and 
6-3, an illustration showing the projected system (WA only) costs are presented 
in Figure 6-10 as a function of input data rates. A detailed block diagram of 
the WA is found on Figure 6-11. 
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Evaluation 


where: 


and. 


of the expression. 


c = .7 us 
f = 3 

j = 100 operations per minor frame 
k = 200 operations per major frame 


u- 1Q0 ‘ c ‘ f ' r i , 
s mf 


r i 

(Mb/s) 

s mf 

(bits) 

n 

u 

(%) 

r i 

(Mb/s) 

s mf 

(bits) 

n 

u 

(%) 

8 

512 

10 

393.8 

20 

512 

10 

984.3 

8 

512 

50 

341.3 

20 

512 

50 

853.3 

8 

512 

100 

334.7 

20 

512 

100 

836.8 

8 

1024 

10 

196.9 

20 

1024 

10 

492.3 

8 

1024 

50 

170.6 

20 

1024 

50 

426.5 

8 

1024 

100 

167.3 

20 

1024 

100 

418.4 

8 

2048 

10 

WJT 

20 

2048 

10 

246.0 

8 

2048 

50 

85.3 

20 

2048 

50 

213.3 

8 

2408 

100 

83.7 

20 

2048 

100 

209.2 

‘ 8. 

4096 

10 

49.2 

20 

4096 

10 

123.0 

8 

4096 

50 

42.7 

20 

4096 

50 

106.8 

, 8 

4096 

100 

41.8 

20 

4096 

100 

104.6 

“ 12 

512 

10 

590.6 " 





12 

512 

SO 

512.0 





. 12 

512 

100 

502.1 





12 

1024 

10 

295.4 





12 

1024 

50 

255.9 





' 12 

1024 

100 

251.0 





12 

2048 

10 

147.6 





12 

2048 

50 

128.0 





, 12 

2048 

100 

125.6 





12 

4096 

10 

73.8 





12 

4096 

50 

64.1 






4096 

100 

62.8 






TABLE 6-2 . BUFFER ANALYZER UTILIZATION FACTOR 
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FIGURE 6-9. BUFFER ANALYZER UTILIZATION FACTOR CURVES 
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Work Assembler Attribute: 

Parameter 

Units 

Projep^ed Cost 

Number of Identical WA 
Subunits 

A 

18 

Not Applicable 

Number of Bytes in Each 
WA Buffer 

B 

3 

Not Applicable 

Number of Buffers in Each 
WA Subunit 

C 

10 to 13K 1 

Not Applicable 

Number of Buffer Analyzers 

D 

1 to 18 


Total Buffer Costs'^ 

Not Applicable 

Not Applicable 

$5,616 to $8,912 4 

Mi sc. Hardware 

Not Applicable 

1 

$10,000 

Total System Cost 

Not Applicable 

1 

20k+ (D)($46K) 5 


Notes: 

1. Costs are based on 13K bytes 

2. Average price for minicomputer surveyed 

3. (3 buffers/umt) x'(18 umts/sys) x (13K bytes/buffer) = 702K bytes/ system - 5.62 x 10 bits/system 

4. At .1 cents/bit (= $.001. bit = $10' 3 /bit): 5.62 x 10 6 x 10~ 3 ■ $5,616. If 4096 bit RAM ICs were 
used at $6.50 each; then {5.6 x 10® / 4096 =) 1372 x $6.50 = $8,912. 

5. Total buffer costs (almost 5 10K) + Misc. Hardware ($10K) = 20K 


TABLE 6-3 . DETAILED WORK ASSEMBLER COSTS 























FIGURE 6-10. TOTAL WORK ASSEMBLER COSTS 
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FIGURE 6-11. DETAILED WORK ASSEMBLER 
BLOCK DIAGRAM 
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6.2.2 MSS Considerations 


The next step is to consider what possibilities exist for the MSS. Under 
NASA/GSFC contract NAS5-24033 Mod 51, ORI submitted a technical report on 28 June 
1976, entitled "Interfacing a High Density Tape Recorder (HDTR) to a Disk Unit." 
This report presented a detailed study of techniques for interfacing a synchron- 
ous data device with a high capacity disk unit. The specific synchronous device 
considered was a high-density tape recorder (HDTR). An HDTR is not a stop/ 
start device such as a standard 7 or 9 track computer compatible tape (CCT) drive. 
A CCT can stop and start within .6 inch interrecord gaps, thus greatly facilita- 
ting, buffer design and timing for the data transfers. However, an HDTR once 
started continues to run and transfer data synchronously. It does not have the 
fast stop/start capability of a CCT. Even though the study looks at the HDTR as 
the input data source, the technical thrust of the report concerns itself with 
how a disk imposes its requirements in buffering and timing. It is permissible, 
therefore, to consider the HDTR as being equivalent to the Work Assembler. (WA) 
since the WA was previously designed to drive a device like a disk. 

The disc unit considered was of the IBM 3330 type. All the disk para- 
meters and example problems in the report were based on 3330 parameters, such 
as rotation speed, head step times, etc. However, the characteristics of any 
other moving head disk unit could be substituted in the developed equations if 
the user wishes to use a different type disc unit. 

Likewise, although the synchronous device considered m the study was an 
HDTR, the material contained in the study is applicable to any synchronous 
device. For example, this material would be useful in establishing a data 
transfer system between a disk and a laser beam image recorder. 

Specifically, the HDTR/disc interface consisted of a large buffer con- 
structed of computer memory. A computer with sufficient memory and software 
to control the buffer operation is used to interface the HDTR controller and 
the disk unit controller. 

Two buffer schemes were found to be practical* 

• Double Buffer. Data is written into one buffer while 
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data is read out of the other buffer. The 
buffers are then interchanged. 

9 Rolling Single Buffer. Data is written into a read- 
out of the same buffer continuously. Care must be 
taken that the write and read data locations do not 
overrun each other. 

In general, a buffer will hold enough data for 2 or more disk tracks. 

The data throughput rate will be maximized for increasing buffer size, increas- 
ing number of words per disk track, and increasing number of disk tracks per 
buffer. For a fixed buffer size, the maximum throughput rate results from 
increasing the number of words per disk track and reducing the number of disk 
tracks per buffer. 

The transfer system is transparent to the data format. Thus, there is 
no need to make the number of words per disc track a multiple or submultiple of 
the data major frame size, since the data maj'or frame format is purely a soft- 
ware format. (The HDTR data is fully synchronous.) 

Data transfer in both directions was considered. The throughput rate 
is independent of the direction of data flow. 

Several different disc data formats were also considered; fixed-sec- 
tor start and staggered sector start. The latter is usually preferable from 
the point of view of throughput rate. 

Table 6-4 summarizes the salient findings of this study. 

If 3330 type disks were used in the SOPS, the most convenient scheme , 

12 

would be to collect "orbit" groups of data. Given 5 x 10 bits/mission, assume 
approximately 100 orbits/mission. This implies approximately 5 x 10^ bits/orbit, 
or 0.63 X 10 10 bytes/orbit. Since a 3300 disk unit holds about 83.9 x 10 6 bytes, 
the product of (0.63 x 10 10 bytes/orbit) / (83.9 x 10 6 bytes/umt) yields 75.09 
disk umts/orbit. This, for obvious reasons, rules out 3330 type disks. 

The next option centers on using HDT's as the MSS. Since an orbit's 
worth of data is aoproximately 5 x 10^ bits, and since a reel of HDT can hold 
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TABLE 6-4. DISK & HDTR INTERFACE ATTRIBUTES 


A 

Total Buffer Size (Bytes) 

32768 

65536 

B 

Bytes/Disc Track 

4012 

8024 

10752 

4012 

8024 

10752 

C 

Disc Tracks/Buffer 

8 

4 

3 

16 

8 

6 

D 

Data Throughput (Mb/s.) 

3.39 

3.54 

3.64 

3.82 

4.02 

4.14 

E 

Disc Utilization {%) 

84 

84 

95 

84 

84 

95 


Note: 

A = B x C (i.e., Total Buffer Size = (Bytes/Disc Track)*(Disc Tracks/Buffer) 





















approximately 1.4 x 10^° bits, the product (5 x 10^ bits/orbit) / (1.4 x 10^ 
bits/reel) yields 3.57 reels of HDT/average orbit. This option is further 
enhanced when one considers that the HDT can handle a data rate of up to 20 
Mb/s. 

To determine the best way to handle bursts of high-rate data, assume a 
worst-case burst at 50 Mb/s for 10 minutes. This hypothetical worst-case burst 
represents (50 x 10^ x 60 x 10) 3 x 10^ bits of high rate per orbit! This could 
represent up to (3/5) 60% or an orbit data group. To transfer this volume of 
data (originally entering the SIPS at 50 Mb/s ), a slow down of only (20 Mb/s)/ 

(50 Mb/s.) 1 to 2.5 is required to capture it from the DOS's tape recorder. 

Thus, if the biggest burst of 10 minutes occurs, 25 minutes of SIPS playback 
time is required. Since an orbit's worth of data will occur during 70 to 80% 
of the projected 100 minute interval, aSIPS lull period of between 20 and 30 
minutes per orbit could easily be utilized for recording the high-rate data for 
better use, and any unprocessed data could be easily deferred until the next 
lull. 

Operationally, it would be advantageous to keep the high rate data on 
separate reels (3 x 10^ bits/orbit) / 1.4 x 10^ bits/reel) - 2.14 reels/orbit 
so that during deferred output processing, this data base can be merged. 

Two parameters (viz. G and H) and the resulting costs have to be 
derived before comparing HDTR to devices like the Terabit System. The two 
parameters are (G) how many MSS units are required and (H) how many bytes of 
storage are in each unit. 

For the recording HDTR's it appears that G equals 3. Two units should 
be on-line all of the time, and a third unit should serve as a spare on-line 
unit. The data rates would be no problem because each HDTR could handle up to 
20 Mb/s. H would be equal to 1.4 x IQ 10 bits, as previously discussed. (For 
the sake of completeness, it will be shown later that 2 HDTR's plus 1 spare 
HDTR are required for playback. Thus, the total number of HDTR's will equal 
5 (G=5) . 

With a device such as -the Terabit System, the primary limiting 
factor restricting its easy utilization is the input data rate - at best 9 6 Mb/s, 
(instantaneous) and realistically 5.6 Mb/s. If the average incoming data, rate 
were 9 Mb/s., at least two units would have to be connected to the WA. Operationally, 
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this would not be any problem since the WA output is easily switched. Because 

g 

the Terabit system uses tapes that hold 46.8 x 10 bits, one orbit's worth of 

in q 

data would be held on (5 x 10 bits/orbit} / (46.8 x 10 bits/reel) 1.07 reels. 
(This is clearly an advantage over HDTs.). Therefore, one would have to have 2 
units plus 1 spare on-line for recording. (As in the case of HDTRs, it would 
be required to have 2 additional output units plus 1 spare— a total of 5 units.) 

The tradeoff between the two appears to be straightforward in favor of 
HDTRs. For the price of just 1 Terabit System (approximately $1.5M), one could 
obtain at least 13 HDTRs plus 13 bidirectional SCIs (13 x (70 + 40)K = $1.43M). 
The proposed intermediate MSS should contain five (5) HDTRs plus five (5) SCIs 
(5 x (70 + 40) = $550K) . It is also recommended that a small disk (the size of 
which has not been determined) be present to facilitate quick-look and future 
P0CC requirements. The proposed MSS is illustrated in Figure 6-12. 
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FIGURE 6-13. INTERMEDIATE MSS COST CURVE 
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6.2.3 Output Processor 


At this point in the processing system we have the following: 

o A precise (byte-by-byte) map of all experiment 
(and ancillary) data 

e Quality control information that may have come in 

at some time after reception and intermediate storage 
of experiment data 

• Uniform work units (same size) 

d High-rate bursts of data (both overlapped data 

that was recorded and transmitted latter; and high 
bit rate experiment data ) blocked into uniform work 
units 

All of the preceding allow for an output processor configuration as 
illustrated in Figure 6-14. As shown, it is highly modular, flexible, and 
resistant to single-point failure. A general data walkthrough is presented 
in the following paragraphs, which are followed by detailed design considerations. 

Blocks (or work units)' of data are transfered from the HDTRs (units 
1 through G) to waiting memories (units 1 through t) via a DMA channel. Since 
the exact decommutation map is known, incoming data can either be decommutated 
upon entry, or the entire work unit can be buffered and decommutated as soon 
as the CPU (units 1 through K) set up the memory-to-memory operations. The 
decommutation process takes, place with the creation or buildup of experiment 
unique data buffers. As soon as a conveniently large experiment data file is 

assembled, the experiment file is sent to a staging disk. When a s-igni-f leant- 

amount of experiment data is built up on the staging disk, an output data 
product is written. 

To set broad operations limits, it shall be assumed that 5 x 10 12 bits/ 
mission are to be processed. With approximately 100 orbits/mission, then 
5 x 10*® bits/orbit is derived. If this data were to go througn tne facility, 

(viz. the output processor) in about 100 minutes (100 minutes/orbit) , then the 
statistical data note would be (5 x 10 10 bits/orbit)/(100 x 60 sec/orbit) = 

8.33 Mb/s. It would therefore be prudent to design to at least 16 Mb/s 
(on 20 mb/s.) to allow for adequate operator rest periods, repairs, etc. 
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FIGURE 6-14. OUTPUT PROCESSOR BLOCK DIAGRAM 












Detailed Data Flow 


A set of HD'S containing a set of orbit data are selected and mounted . 
for playback. The data are on between 4 and 6 reels (normally 3.57 reels) All 
of the reels except one or two contain the regular low and medium-rate experiment 
data. The regular data for example would be played back on HDTR #1 and the high- 
rate burst data on HDTR #G. The RM would set up the playback of high-rate data 
so that its data would be placed approximately in the GMT time slot and so that 
the removal of overlapping data and chronological ordering functions could be 
performed. This is illustrated in Figure 6-15. The intent at this point is to 
'line up work units for processing so that a minimum amount of data handling is 
required. 

For this study, it is not known how the experiment data will show up on 
SIPS lines. To insure a robust SOPS desiqn, one must then formulate a reasonable 
set of worst-case situations. In Table 2-1, a hypothetical experiment mix is 
given. Line assignments can be made according to two different schools of 
thoughts. The alternatives are: 

I. - Assign all high-rate experiments to separate lines 

- Assign all medium-rate experiments to separate lines 

- Assign low-rate experiments to separate lines 

- Spread out all remaining experiments uniformly over 

all used lines. 

II. - Assign all experiments to the minimum number of lines 
so long as the maximum bandwidth is not exceeded. 

The advantages and disadvantages of each alternative need not be 
presented here: the first option would have 48/18= 2.67 experiments per line 
and the second could have as few as 3 or 4 lines active and consequently up to 
42 or 44 experiments on one line. Table 6-5' , presents a hypothetical mix with 
the worst attributes of both approaches. In this table, each line is active 
at least 50% of the time, and since the two "A" experiments only occur at most 
5% of the time, the verylow-rate experiments (which collect data 100% of the 
time) are also assigned to lines 1 and 2. Even if all "E" and "F" experiments 
were on at their highest rates, they would only represent £(10 x 0.1) + (20 x 
0.01) = 1 + 0.2 =] 1.2 Mb/s. Thus the memory system would be illustrated as 
shown in Figure 6-16. 
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TABLE 6-5 

A HYPOTHETICAL DISTRIBUTION OF EXPERIMENTS OVER 
18 SIPS LINES 


SIPS OUTPUT 
DATA LINE 

EXPERIMENT 
QUANTITY & 
CLASS 

% OF TIME ON 
FOR EACH 
EXPERIMENT 

MAXIMUM (PRERECORDED) 
BIT RATE ON EACH 
SIPS LINE 

(Mb/s) 

1 

1A + 10E 

<5 + 100 

30 ; (10 x .1 = ) 1 

2 

1A + 20F 

<5+100 

30 , (20 x .01 = ) .2 

3 

IB 

< 10 

10 

4 

IB 

< 10 

10 

5 

IB 

< 10 

10 

6 

IB 

< 10 ' 

10 

7 

1C 

100 

1 

8 

1C 


1 

9 

1C 

100 

1 

10 

1C 

100 

1 

11 

ID 

< 50 

1 

12 

ID 

< 50 

1 

13 

ID 

< 50 

1 

14 

ID 

< 50 

1 

15 

ID 

< 50 

1 

16 

ID 

50 

r 

17 

ID 

■<, 50 

i 

18 

ID 

< 50 

i 
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The next step is to examine the attributes and functions of the "L" 
memories as shown in Figure 6-14. If these memories are linked to the "K" 

CPU's (K does not necessarily equal 1), the maximum I/O Rate (as, selected from 
Table 4-7) is (2.5 M words/sec. x 16 bits/word = 40 Mb/s.) It should be 
pointed out that this value is a computed coverage, and many mini-computers (for 
example) could be faster.. In general, the I/O rates can be expressed as. 



r dma 

r in + r out + Overhead 

where: 

r dma 

= DMA channel rate ( 40 Mb/s) 


r in 

= Input channel rate ( 20 Mb/s) 


r out 

= Output channel rate ( 20 Mb/s) 


It has been found in past experiences that R oyERHEAD can amount t0 up 

to 10% of R qma in most good memory systems. Thus for a steady state situation, 
^IN = R 0UT = ^ Mb/s* This would appear to limit the size of the memory subsys- 
tems. So that the proposed design may accommodate this constraint, movement 
of data in the memory subsystem must be understood. 

Each buffer is fully packed with a "set" of data. Upon entry into 
the memory (as shown in Figure 6-17), data elements a^ through a 7 are initially 
set into buffer number 1 with data elements b.-* b^ and These three 

groups must be separated (decommutated) into their own separate buffers (1, 2, 
and 3 as illustrated in Figure 6-17). The next data group may or may not contain 
the next buffer group. Therefore, it must take less time to process and 
handle a data block than to either write or read these data elements. The 
time to process a memory-to-memory operation can be defined as: 



Tp = process time 

f = multiplicative factor (to convert cycle 

time ta a memory to memory move instruction) 

c = cycle time. 
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FIGURE 6-16. SIMPLIFIED MEMORY 
HIERARCHY DIAGRAM 
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Let 


and 


f = 1, 1.5, 2, 2 5, or 3 
c = 0.7 x 10“6 sec 


Then for f = 1 and 

c = 0.7 jjs 


T 


P 


8 


bit 

byte" 


1 x .7 x 10 


-6 


sec 

byte 


11.4 x IQ" 6 bits/sec 


for 

f = 1.5 

for 

f = 2.0 

for 

f = 2.5 

for 

f = 3.0 


7.62 Mb/s 
5.21 Mb/s 
4.57 Mb/s 
3.81 Mb/s 


It is evident from the above computations that the candidate memory/ 
CPU must be as fast as possible on a memory-to-memory instruction. (For a 
point of interest, if T p = 20 Mb/s, and f = 2, then c would have to equal 
0.2 ps). Another approach to this problem would be to have high-speed, solid- 
state (RAM) devices as used in the WA. 


It appears that the only safe way to be prepared for any mix experi- 
ments is to double-buffer 18 lines and triple-buffer each experiment to ensure 
compatible HDTR - DISK interfacing. At 10752 bytes/buffer then ((2 x 18) + 

(3 x 48)) x 10752 bytes = 1.94 x 10 6 bytes (which also equals 15.48 x 10 6 bits). 
At 0.1 cents/bit this buffer would cost $15,480, and at .01 cents/bit, this 
buffer would only cost $1,548. 
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The output processor CPUs (1 through k) as illustrated in Figure 6-14 
shall perform the following operations on data within the previously discussed 
memories: 

a Output data accounting 
a Quality checking 

a Decommutation 

a Data Store 

a Time Validation 

e Overlap removal 

a Data fill 

a Memory anci 1 1 ary 

It would now be appropriate to consider the type of computational unit 
used in the Work Assembler, i.e., the average minicomputer as specified in 
Table 4-7. 

The workload for the output processor was specified earlier in 
Table 4-11 and is summarized below: 


Function 

Estima' 

m.f. 

:ed lines 
M.F. 

of code execi 
Orb.G. 

j 

jted per: 
Exp. File 

Output data accounting 

50 

100 

5000 x E 

50,000 

Quality check 

50/200 

50/200 

500 X E 

5,000 

Decommutati on 

50 

0 

0 

0 

Data store 

0 

0 

50000 X E 

10,000 

Time Validation 

75 

0 

0 

0 

Overlap removal 

0 

0 

20000 x E 

0 

Data fill 

0 

0 

5000 x E 

10,000 

Merging ancillary data 

0 

0 

5000 x E 

0 


Subtotals 275 200 40500 x E 75,000 
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The above concept can be formalized analytically as "u", to 
express the ratio of work - to be done versus system capability. Thus, one 
of the tools to determine the acceptability of the candidate computa- 
tion unit is a determination of the system utilization (u) factor. This rela- 
tionship can be expressed as: 



1 


f x c 


Where* 


And: 
Where : 


u = 

V 

s mf~ 

S MF 
J = 


1 = 
m - 

S 0G : 

S EF 
k = 

f = 
c = 
s 


computer utilization (%) 

input data in Mb/s. 

size of a minor frame in bits 

- size of a major frame in bits 

total number of lines of code executed for 
each minor frame of data 

total number of lines of code executed for each 

total number of lines of code executed for each 

= size of an orbit group in bits 

= size of an experiment file in bits 

total, number of lines of code executed for each 
.of data 

multiplicative factor (to convert cycle time to 
cycle time in seconds of candidate CPU 

= n s mf 


MF 

n - integer number of minor frames per major frame 


orbit group 
experiment file 


major frame 
instruction time) 


For ease of data manipulation, the expression for u reduces to: 


u 


100 • 


c * 


f 



+ 1_ + m 

S 0G S FF 


Because the nature of the input data stream is not narrowly defined 
as yet, it would be advisable to examine u with different factors being 
varied. The above compact expression obviously is very sensitive to 



certain combinations of driving factors. The objective is to determine the worst- 
case which drives up the system utilization. The factors which are relatively 
fixed are "c" at .7 us (from the minicomputer characterization section), "f" at 
3 (to very closely approximate load and store operations), "j" at 275 (best 
known approximation), "k" at 200 (best known approximation), "1" at 40,500 
x E (best known approximation), and "m" at 75,000 x E (best known approximation). 


The expression for "u 11 can be simplified (just for the previous 

case) to: 


u = (100) ( - 7 x 10 -6 ) (3) r 1 



^275 + 



40500 x 48 x 75000x48 
5 x 10 10 5x1 0 12 / 48 


= (2.1 x 10" 4 ) r n 


"l 

( 275 + 200) 

+ 7.34 x 10" 5 

_ s mf 

1 — J 



Before searching for the worst case, u should be evaluated to establish 
a baseline operating point. 

Typical values are as follows: 

s f = 4096, 2048, 1024, 512 bits 

r - 8, 12, 20 Mb/s 

n = 100, 50, 10 

Table 6-6 and Figure 6-x illustrate these findings. 
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TABLE 6-6. 

OUTPUT PROCESSOR UTILIZATION FACTOR 


■H 

HU 

n 

u 

wm 

EH 

n 

u 




(%) 




(*) 

8 


m 

968 

B| 

HE 

10 

2420 

8 

■B 

Wm 

915 

mm 

19 

50 

2289 

8 

512 

100 

908 

20 

512 

100 

2272 

8 

mm 

10 

454 

ES 

eh 

10 


8 

mmm 

50 

457 

S9 


50 

1144 

8 

Wm 

100 

454 

20 

ia 

100 

1136 

8 

2048 

cs 

242 

WM 

2048 

E9 

605 

8 

2048 


228 


2048 

rl 

572 

8 

2408 


227 

20 

2048 

100 

568 

8 

4096 

10 

1 

20 

fl 

10 

605 

8 

4096 

50 

■BE 

20 


wSm 

286 

8 

4096 

100 

iff! 

20 


EuuB 

284 

12 

512 

10 

1452 





12 

512 

50 

1373 





12 

1024 

100 

682 





12 

2048 

10 

363 





12 

2048 

50 

343 





12 

2048 

100 

341 





12 

4096 

10 

181 





12 

4096 

50 

172 





12 

4096 

100 

170 
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INPUT DATA RATE (Mb/s) 



FIGURE 6-18. UTILIZATION CURVES FOR THE OUTPUT PROCESSOR 



TABLE 6-7. OUTPUT PROCESSOR TITLE COSTS 


Attribute: 

Parameter 

Units 

Projected Cost 
($) 

Number of Identical Buffers 

L 


Not Applicable 

Number of Bytes in Each 
Buffer 


> 10K 

Not Applicable 

Total Buffer Costs 3 

Not Applicable 

Not Applicable 

($5,616 to $8,912 4 ) 
Aoorox. $10,000 

Number of Output Processors 

K 

2 to 24 1 

$46K ea. 2 

Mi sc. Hardware 

Not Applicable 

1 

50,000 

Total System Cost 

Not Applicable 

1 

60K + (K) ($46K) 5 


Notes : 

1. Estimated range 

2. Average price for minicomputer surveyed 

3. (3buffers/umt) x (18 units/sys) x (13K bytes/buffer) = 702K bytes/system = 5.61 x 10 6 bits/system 

4. At .1 cents/bit (= $.001. bit = $10' 3 /bit): 5.62 x 10 6 x 10~ 3 = $5,616. If 4096 bit RAM IC‘s were 
used at $6.50 each; then (5.6 x 10 6 /4096 =) 1372 x $6.50 = $8,912. 

5. Total buffer costs (almost 10K) + Misc. Hardware ($50K) = $60K 
















M $ 


FIGURE 6-19. COST CURVES FOR OUTPUT PROCESSOR 



Staging Devices 

As illustrated earlier in Figure 6-14, a number (T) of devices are 
required to stage the output data files for either 1600 bpi , 6250 bpi, HOT, or 
communication lines. As buffers become ready from the "L" memories (as shown 
in Figure 6-14), the buffers should be placed into various staging positions 
so that an experiment data file can be conviently built up. One major candi- 
date for this role would be a large disk. It will be assumed that a good start- 
ing point would be to consider the type of disks as highlighted in Table 4-8. 

Since the buffering of data and the operations on it are essentially 
transparent when the output processor is in operation, the minimum number of 
discs required to sustain the system throughput would be defined as- 

T = R MR 

r dw 

where: 

T = 

R MR 

r dw 

where: 

R DW = P MAX ” °DR 

Rp£ = Maximum sustained read rate of a single disk 

D 

MAX = Maximum sustained total I/o rate of a single disk 

Based on data entries in Table 4-8, the range of sustained data rates 
(R dw + R^) for 3330 type of disks is between 2.6 and 4.5 Mb/s. If no overflow 
or underflow is a set design goal, then R DW ^ 2.25 Mb/s =“ R^. Figure 6-20 
illustrates the relationship between R MR and T. The figure does not reflect 
consideration for spares. 

As illustrated in Figure 6-20, two sets of curves are illustrated — 
a computed "T" curve and a practical "T" curve. For example, at 8 Mb/s., the 


number of disk units 

= Maximum total data rate from all MSS devices 
being read into the output processor 

= Maximum sustained write rate of a single dis>k 
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FIGURE 6-20. COMPUTED AND PRACTICAL 



OF DISK DRIVE 





computed value of T is 3.56, thus requiring T to be rounded up to 4. Attention 
is drawn to the point when R MR equals 16 or 18 Mb/s. Due to rounding up at 
16 Mb/s., one automatically obtains the capability to handle 18 Mb/s. 

These values are translated in dollar amounts in Figure 6-El. For an 
absolute minimum system curve, ABODE could be considered. It uses the minimum 
number of controllers and disk drives. It appears worthwhile to consider using 
two controllers, especially when the 16 Mb/s. operating point is approached. 
This cost-curve is FCDE, as shown in Figure 6-21. 
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TOTAL INPUT DATA RATE (R, 



K $ 


FIGURE 6-21. STAGING DISK COSTS 






6.2.4 Peripheral Pool (Output) 

Three sets of output peripherals are required* 

s Dual density magnetic tape recorders (1600/6250 bpi ) 
a High density tape recorders 

a 56 Kb/s. communication equipment 

The cost and performance of these devices were presented earlier in Table 4-8. 
Because of given output product distributions, it is probable that during 
significant portions of time, only 1600 bpi tapes would be produced. This implies 
an I/O rate limited to 2.56 Mb/s. 

For a facility to sustain any constant I/O rate, pairs of tape transports 
are required. Figure 6-22 illustrates the cost curves for all magnetic tape 
transports as a function of data rates that can be supported. Table 6-8 tabulates 
the costs and data rates that can be supported with 1600 bpi transports. 

The cost curves for 56 Kb/s. communication devices are not shown because 
they would not be discernable in Figure 6-22. At (approximately) $3,000 per 
communication line, even ten units would only represent $30,000. 
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SUSTAINED DATA RATE {Mb/s ) 
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FIGURE 6-22. PERIPHERAL COST CURVES 



TABLE 6-8. CONTROLLERS AND TAPE TRANSPORTS 


No. of 
Controllers 

No. of 

1600 bpi 

Drives 

Costs 
($ 100K) 

Data 
Rate 
(Mb/s. ) 

1 

2 

.986 

2.56 

1 

4 

1.58 

5.12 

1 

6 

2.18 

7.68 

1 

8 

2.78 

10.24 

2 

10 

3.77 

12.84 

2 

12 

4.37 

15.36 

2 

14 

4.97 

17.92 

2 

16 

5.57 

20.40 

3 

18 

6.56 

23.04 











Resource Monitor (RM) Requirements 

The Resource Monitor performs the following functions: 

1. Accepts jnput scenario data 

2. Accepts^-input maps of TLM 

3. Performs scheduling for all resources 

- Work Assemblers 

- Storage 

- Output Processor 

- Output Switch 


4. Allocates and monitors resources to maintain schedules 

5. Collects and stores input accounting data 

6. Collects and stores output accounting data 

7. Logs hardcopy of all accounting data 

8. Prints all necessary forms for transmittal 


9, Provides a query capability for system status 
Figure 6-23 shows a generic RM. A detailed analysis of its functions follows 



This data is provided as tape input and is defined a priori. 

It can be provided on an orbit- by-orbit basis, or it can describe a series 
of orbits. Basically the data contained on the tape are* 

» The experiments which will be on for the scenario 
i The DCS lines to which they will be connected 

e The start and stop times of the experiments 

§ The ancillary data to be used by the experiments 

2} Accepts input maps of TLM 

This data is again provided as tape input and is defined a 
priori. It should be provided for the overall mission and updated 
in the event of a real-time TLM formatchange. The data should contain: 
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• SCHEDULE 
DATA 

• STATUS 
REPORTS 

• TRANSMITTAL 
DATA 



CJl 

cr> 


* 


? From 

SIPS 


* 


FRONT 

END 

PROCESSOR 



FIGURE 6-23 




SELECTORS 


RESOURCE MONITOR 






9 A description of the experiment TIM frame format, for all 
experiments. 

9 A description of the TLM formats for all other data. 

NOTE: These data_shqu]d_be byte^oriented. 

3) Performs scheduling for all resources 

Using the two inputs just described, the RM performs the neces- 
sary algorithms to allocate units of work to each of the resources ■— 

within the SOPS and to ensure that the use of resources is maximized 
and that a smooth workflow takes place. This is performed for the 
specific scenario input. The RM typically allocates buffers, storage 
and output devices. 

4) Allocates and monitors resources 

Once a resource is allocated, it must be continuously monitored 
to ensure that the resource “is performing LJL 0 IJectly. _ This is accomplished 
by handshaking with the various portions of the system. Typically 
this involves the following functions* 

« Allocate a Uork Assembler to a DCS line 

9 Allocate a storage unit to the work assembler 

« Allocate an output processor to this data, and define 

the work to be done, e.g., what experiments to segregate, 

what ancillary data to compile etc. 

9 Allocate output processor media by experiment 

9 Obtain an indication of full buffers within the time 
expected 

9 Obtain an indication of Work Assembler work units complete. 

e Obtain an indication of output processing completed, and 

o/p media written 

• Record and flag any failures of work incomplete within 
expected time (watch dog) 

5) Collects and stores input accounting data 

As the input data is collected in the work assembler, it will 
gather information concerning the nature of the data. This information 
will be returned to the RM for storage and is used to track the 
resource performance. This data includes*. 
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9 


The GMT for each frame 
9 The experiment ID for each frame 
9 The number of bytes collected per frame 

t The number and position of missing or known incomplete 
frames 

• The number of detected errors in each frame 

» The number of frames collected per unit time 

9 The total number of frames collected per scenario 

6) Collects and stores output accounting data 

As the data is processed in the output processor and passed 
to the output media, the output processor collects information, which 
is then passed to the RM. This data includes: 

# Start and stop times in GMT 

9 Number of frames processed for unit time 
9 Total number of frames processed for an experiment 
9 Number and position of overlapped frames found 

9 Number and position of filled frames 

9 Time validation errors 

9 Number of tapes written by experiment 

9 Amount of data transmitted over links per unit time 

7) Logs hardcopy of all accounting data 

All of the above data are made available in hardcopy. 

System performance data is also hardcopied. 

8) Prints all necessary forms 

Using the above data, any forms that must be transmitted on tape 
to the experiment can be printed automatically. 

9) Provides a query- capability 

All the data that is retained with the system should be made 
available interactively, via alphanumeric keyboard displays. 
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6.2.5. 1 Configuring the RM 


The resource monitor performs three major functions 

• Schedules resources 

a Monitors resource performance 

s Collects and displays accounting data 

Thus, the RM can be illustrated functionally in Figure 6-24. Each of 
the three functions is shown as a separate box. 

Figure 6-24 shows a schedule processor whose function is to allocate 
resources for the various scenarios. It u^es the input data provided. The 
resources allocated are then communicated to the schedule monitors whose function 
is to track the performance of the resources and to relay accounting data to the 
data collection processor. The schedule processor also stores its telemetry format 
data on the disc for use by the collection processor. 

The collection processor maintains the accounting data, prints hard 
copy, and provides interactive query capability. There are defined j schedule 
monitors. The number of these required is a function of resources monitored, the 
type of machine used, and the actual amount of information to be fed through 
them. 

It is necessary to compute the number and size of processors that would 
be required to perform the RM functions for each of the data flows defined for 
the main processing facility. Prior to this computation, the operations of the 
RM must be described. 

6.2. 5. 2 RM Operations 

The scenario of operations for the RM is defined in the following way. 

The scheduling of resources is performed statically. The data is provided to the 
monitor "off line", and resources and operations are scheduled before the opera- 
tions begin. Figure 6-25 shows the order in which the data in input, and Table 
6-9 shows the types of data used and the expected output products. This indi- 
cates that the system is not dynamically reconfigured but is mainly configured 
prior to mission start. It is within only the slacker processing times that a new 
scenario is introduced. 
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FIGURE 6-24. RM CONFIGURATION 
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FIGURE 6-25. TIMELINE FOR INPUT DATA TO RESOURCE 
MONITOR, FOR USE IN SCHEDULING 


TABLE 6-9. WORK ACCOMPLISHED AT RESOURCE MONITOR 


CONFIGURATION STEPS 


INPUT 

DATA 

TYPE 

DATA 

CONTENTS 

OUTPUT DATA 

SYSTEM 

Describes and Quantifies 

Listing of System Components 


all Resources: 

with assigned labels. 


9 Computers 
9 Disks 
# Tapes 

9 Buffer Sizes, etc. 

(Addresses, etc.) 

TELEMENTRY 

Describes the contents 


MAP 

of all experiment and 
TLM formats 


SCENARIO 

Describes the experiments 

In combination with che 

DATA 

and other data which will 

system data & TLtl Map pro- 


be on and collected for 

duces a schedule list in 


the desired orbit, orbits. 

hard copy, showing: 


or other period of time 

g Assignment of tapes 
to experiments 

9 Expected time of tape 
comp! en on in chronolo- 
gical order 

9 Work orders to operators 
and assignments 

e Transmittal orders for 
completed tapes 

» Data trace checkpoints 
Non Hardcopy 

9 TLM Maps to Resources 

» Assignment & Interconnec- 



tion of system components 
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A scenario is defined as the description of an orbits’ worth of data. 

This is consistent with the SOPS facility scenarios previously described. How- 
ever, such a definition is not mandatory. A scenario could be described as a 
number of orbits, or as a time interval. The RM functions would remain unchanged, 
only the parameter keys would differ, and that difference would have no impact 
upon system operation. 

6. 2. 5. 3 Sizing the RM 

The RM must be capable of performing its functions for both of the data 
flows being considered. The heaviest workload imposed upon the RM is maintaining 
resources and collecting accounting data. As previously explained, this is the 
only real-time function undertaken. Thus, emphasis is placed upon this function. 

To facilitate a discussion of both data flows, the SOPS can be considered 
as two parts, a front-end, and a back-end processor. (This is consistent with the 
previous diagrams). Because both processors are considered to perform the same 
type of work, a single set of computations will suffice for both. Computations will 
therefore be performed only for the front-end processor work. A multiplying 
factor of 2 will translate the results into terms appropriate to the back-end. 

In order to establish a base line set of parameters, sizing is performed 
based on a variable number of bytes transferred per buffer, with a variable number 
of operations being performed on each byte. 

Thus, it is possible to derive utilization factors based on various 
data rates. All that is required then is to pick an operating point for 
processor utilization given an input rate. 

At the same time, the volume of accounting data required to be stored 
on-line and archived, is computed for a chosen operating point. (A change of 
operating point requires only a simple recomputation of volume, and a decision 
concerning the cost-effectiveness of the storage media required to maintain this 
volume). The computations follow. 

For each buffer accounting, data is collected. We will collect N 
bytes of data. 

R i 

Buffer rate = gg— buffers per sec 
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where 


R = input rate in MB/s 

B = buffer size in bytes 
8 = number of bits in a byte 
NR 

Therefore, rate of collection of data = i_ bytes/sec. Now let us perform P 

operations on each byte. Therefore, we 8 ^ave jjjp operations/sec. 


The capability of a machine with 0.7 vs cycle time at an average of 

5 

3 cycles/operation is 2.1 vs per operation or 4.76 x 10 operations per second. 
The utilization factor of a machine is described as 

•I _ 1nn Number of operations/sec to be performed * 

capability in ops/sec 7o ' 

So that in this case we have 


U = 100 x 


PNR i 

~W~ 


4.76 x 10" 


10 100 PNR 


8B x 4.76 x 10" 


2.63 x 10~ 5 PNR. 

i 


Now the buffer size (B) is 


fixed at about 10 Kbytes 

U = : l 2 ' ;6 3- x,:l ° 5 PNR. % 
10 x 10 d 1 

= 2.63 x 10 -9 PNR n % 
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We will now compute U for various combinations of parameters, thus 

P (number of operations = 1, 5, 10, 20 
N (number of bytes)/ buffer = 1» 2, 4, 8 

R (input rate) =8, 12, 20 Mb/s. 

The following values are computed. 


TAELE 6-10. RH UTILIZATION 


N 

P 

... 

U (% utilization) 

Bytes 

Ops 

8 Mb/s 

12 Mb/s 

20 Mb/s 

1 

1 

2.1 x 10" 2 

3.16 x 10" 2 

5.26 x 10" 2 


5 

1.05 x 10" 1 

1.58 x 10' 1 

2.63 x 10" 1 


10 

2.1 x 10" 1 

3.16 x 10" 1 

5.26 x 10" 1 


20 

4.2 x 10" 1 

6.31 x 10" 1 

1.05 

2 

1 

4.21 x 10“ 2 

6.31 x 10" 2 



5 

2.1 x 10 -1 

3.16 x 10" 1 



10 

4.21 x 10 -1 

6.31 x 10" 1 

1.05 


20 

8.42 x 10" 1 

1.26 

2.1 

4 

1 

8.42 x lO" 2 

1.26 x 10 _1 

2'. 10 x 10" 1 


5 

4.21 x 10" 1 

6.31 x 10"* 1 

1.05 


10 

8.42 x 10' 1 

1.26 

2.10 


20 

1.68 

2.52 

4.21 

8 

1 

1.68 x 10 -i 

2.52 x 10 -1 

4.21 x 10** 1 


5 

8.42 x 10' 1 

1.26 

2.10 


10 

1.68 

2.52 

4.21 


20 

3.37 

5.05 

8.42 


These values are plotted in Figures 6- through 6- for the 
various R.'s with both P and N as parameters. 
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FIGURE 6-29. RESOURCE MONITOR UTILIZATION AT 8 Mb/s WITH 
N CONSTANT 




FIGURE 6-30. RESOURCE MONITOR UTILIZATION AT 12 Mb/s WITH 
N CONSTANT 
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FIGURE 6-31. RESOURCE MONITOR UTILIZATION AT 20 Mb/s WITH 
N CONSTANT 



These curves make it apparent that for either low byte rate or low 
operations, a single processor is capable of performing both input and output 
accounting functions. 

If, for example, the input data rate to the front-end processor was 
8 Mb/s and we wished to collect 8 bytes per buffer and perform 20 operations 
per byte, then the utilization would be 3%. And if the back-end processor rate 
were 20 Mb/s and we collect 8 bytes with 40 operations, the utilization is 10.5% 
for a total of 13.5%. Thus, from Figure 6-24, j reduces to one, which leaves 
sufficient computing capability to handle the other functions within the same 
machine. 

In the above example, we> collected a total of 16 bytes/buffer so that 
the volume of data collected is: 

v = # buffers/mission x Nbytes/buffer 
= 6.25 x 10 7 x 8 bytes 

= 10^ bytes 

Number of bytes collected or g 

per orbit = 6.25 x 10° x 8 bytes 

= 5 x 10 6 bytes 

Now, if a 3330 disc is used for on-line storage, then we can maintain 

200 x 10 orbits on 40 orbits and to retain this data on 6250 bpi tapes, we 
5 x 10° 

will require: 

10 bytes tapes/mission 

1.5 x 10^ bytes 

= 6* 6 tapes 

The use of a single processor although possible, does have one major 
disadvantage: single point failure, which can be catastrophic to the facility. 

It is useful, therefore, to perform same computation directed towards improving 
processor processor utilization, and providing backup. 

If there are two identical processors, one for input accounting, and 
one for output accounting and if the same buffer size is used in both cases, then 
a redundant configuration can be arranged so that if one processor fails, the 
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other could do both jobs. To achieve this, we will set the utilization at 50%. 
This can be achieved by varying two parameters: work done per byte (P) and the 
number of bytes extracted (N). Ultimately, the amount of data collected is 
reflected in the amount of storage require to retain accounting data. 

Therefore, let us use the P parameter curves, extract the various 
values and N's involved, and then compute data volumes. The N values are 
rounded to the closest multiple of bytes. 


p 

Ops 

N = Number of bytes for 5 

3% operation 

8 

Mb/s 

12 
Mb Is 

20 

Mb/s 

1 

2048 

1536 

1024 

5 

512 

384 

256 

10 

256 

196 

128 

20 

128 

96 

64 


12 

Now it is given that the mission vol- = 5 x 10 bits 
ume , . 

= 6.25 x 10 11 bytes/mission 

= 6.25 x 10^ bytes/orbit 
— 3 

Now the buffer size is given as 10 x 10 bytes. Therefore, the number 

_. . , , 6.25 x 10 11 bytes/mission 

of bytes collected per mission = — * 1 - 

10 x 10° bytes/buffer 
= 6.25 x 10 7 buffers/mission 

5 

or 6.25 x 10 buffers/mission 

Now the number of bytes collected per mission = N x number of 
buffers/mission or N x number of bytes/orbit. 

The values of N from Table 6-10 are now substituted, and the results 
obtames are tabulted m Tables 6-11 and 6-12. We will now consider 
the number of bytes collected per mission in relation to the total 
number of bytes per mission as a ratio, i.e., number of bytes/mission 
divided by the number of bytes called per mission. These results are 
plotted in Figure 6-32. 
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TABLE 6-11. NUMBER OF BYTES COLLECTED 



9 Mb/s 
PER MISSION 

12 Mb/s 
PER MISSION 

20 Mb/s 
PER MISSION 

i 

1.28 x 10 11 

9.6 x 10 10 

6.4 x 10 10 

5 

3.2 x 10 10 

2.4 x 10 10 

1.6 x 10 i0 

10 

1.6 x 10 10 

1.2 x 10 10 

8 x 10 9 

20 

8 x 10 9 

6 x 10 9 

9 

4 x 10 


TABLE 6-12. RATIO OF MISSION BYTES 


P 


— mm 


OPS 

8 Mb/s 

12 Mb/s 

20 Mb/s 

5 

19.53 

26.04 

39.06 

10 

39.06 

52.08 

73.08 

20 

78.13 

,104.17 

156.25 
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FIGURE 6-32. MISSION BYTE RATIO 



Let us suppose now that we choose a ratio of 500:1 (i.e., for every 
500 data bytes, there is one accounting byte for both input and output). To cal- 
culate the data values only for input, we have: 

§ bytes collected per mission 

_ 6.25 x 10 11 

500 

g 

= 1.25 x 10 bytes/mission 

= 1.25 x 10^ bytes/orbit = 12. 5M bytes/orbit 

Now the capacity of a 3330 disk is 200 x 10 bytes, and on one 
drive, we can collect* 


200 x 10 6 
12.5 x 10 6 


orbits of data 


= 16 orbits worth of data 

And for scenario #3, we require to retain only 3 orbits worth on 


line. 


Now if all of the data is archived on 6250 bpi tape, then we require 
for a capacity of 1.2 x 10 9 bits = 1.5 x 10 8 bytes. 


g 

1.25 x 10 tapes/mission 
1.5 x 10 8 


=8.3 reels 

say, 9 reels, which is a reasonable number. 

And if we now also consider output accounting, then, for the same 
operating point, we simply double the number of tapes and halve the number of 
orbits or amount of data that are retained on-line. The result of 18 tapes and 
8 orbits is still within the scenario requirements. 
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Referring to Figure 6-32, at a 500:1 ratio, we now discover that at 20 
Mb/s we can perform 80 operations per byte and at 8 Mb/s we can perform about 
140 operations per byte 

Thus, full on-line redundancy can be obtained with the configuration 
of Figure 6-33, which illustrates a four computer system. 

The schedule computer and accounting computer could be collapsed into 
one, leaving full monitor redundancy, while possibly degrading either schedule 
or data accounting functions or both. 

Comparative costs for the three configurations are shown m Table 

6-13. 
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FIGURE 6-33. FULLY REDUNDANT RM CONFIGURATION 
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TABLE 6-13. COMPARATIVE COSTS OF THREE RESOURCE MONITORS 


ITEM 

SINGLE 

COMPUTER 

PARTIALLY 
REDUNDANT 
(3 COMPUTERS.) 

FULLY 
REDUNDANT 
(4 COMPUTERS) 

Computers at 
$46K each 

* - $46K 

$138K 

$184K 

Core Memory 

At 10% of a Single 

CPU 

4:6K 

4.6K 

4.6K 

6250 bpi Tape and 
Controller 

68. 6K 

68. 6K 

68. 6K 

3330 Disc and 
Controller 

95. 5K 

95. 5K 

95.5K 

Line Printer and 
Controller 

10K 

10K 

10K 

Display Terminal 

5K 

5K 

5K 

TOTAL 

$229.7 

$321. 7K 

$367. 7K 

% DIFFERENTIAL 

0 

+■ 40% 

+ 70% 


179 

































6.3 


ARCHITECTURE NUMBER 2 


Architecture number 2 is illustrated in Figure 6-34. This architecture 
fully supports data flow number 2 (as previously illustrated in Figure 6-2). 

A brief system utilization walkthrough is presented below. 

Space! ab and GMT data enter the system via multiple SIPS output lines. 

ii 

It is assumed that all data on these lines are commutated (viz., lines 1 through 
18). The incoming data enters a Work Assembler (WA), where data is decommutated 
and conveniently large experiment buffers are built. Additionally, ancillary 
data are extracted from the appropriate data lines. When the appropriate Mass 
Storage Unit is available, a large experiment buffer load of data is written 
out. This process continues to roughly correspond to the time of one orbit 
(approximately 100 minutes). During this interval, precise information con- 
cerning the actual decommutation of experimenter data is collected and sent to 
the Resource Monitor (RM). This data collection and temporary buffering of 
experiment data continues in units of "orbits" until the end of the mission. 

At some chosen point in time (i.e., corresponding to either the 2nd 
or 3rd orbit), the output processing of data begins. The output subsystems 
receive scheduling information from the Resource Monitor so that any required 
data editing may be completed, the emphemens and attitude data reformatted and 
written, the ancillary data merged, and the data products finally formatted and 
written. Peripherals, as required, are selected! from a pool (as shown in 
detail in Figure 6-5), and are assigned to any of the "K" subsystems (as shown 
in Figure 6-6 ). 

5.3.1 Work Assembler 

The first major assembly of equipment in the architecture is the Work 
Assembler (WA). It is illustrated in Figure 6-35. As shown, it has 19 primary 
inputs, 18 data input lines (a one-to-one correspondence with the 18 SIPS out- 
put lines), and one GMT line from the SIPS. Associated with each SIPS data 
input line is an interrupt line which notifies the WA of incomplete data frames, 
error situations, end of data frames, etc. 

In this architecture, the WA functions as in the previous architecture. 
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i.e., it smoothes the input data stream so that large units of work can be 
conveniently stored on an interim MSS. At the center of this scheme is a three- 
tier set of buffers (V, W, and X). A logical layout of these buffers is pro- 
vided in Figure 6-36. For SIPS line number 1, for example, assume that incoming 
data is commutated (i.e., multiple experiments are interleaved) and that "a" 
types of major frames of data are possible. The data stream enters the WA via 
the V buffer. The associated Buffer Analyzer (BA) looks for information 
identifying the type of major frame, what experiments are inside the 
major frame, what the GMT time tag is, etc. The length of this "V" buffer is 
at a minimum, 4 minor frames (since the first four minor frames of any major 
frame contain these data). Once the BA determines or confirms one type of the 
maj'or frame, the major frame is then shunted to a W (1 through "a") buffer. 

This "W" buffer is at least one major frame in length (a maximum of 4096 x 
256 - 1.05 x 10 bits). If, for example, the major frame is a type "a" major 
frame, then the data contained in it is exclusively experiment "C" (see 
Figure 6-36). If, on the other hand, the major frame is a type "2" (as illus- 
trated in Figure 6-36), then data elements belonging to experiments 2, 4, and 5 
would then be shifted to output buffers X-j , X 2 and X g . This is basically how 
the three tier set of buffers decommutates the incoming data stream. Output 
buffers X-, through X rf (d = 48 in this study) fill up and when each fills, the 
BA and the RM are notified that a large group of decommutated data is ready to 
be written onto a MSS, (It may be possible to do away with the V buffers and 
absorb its functions into W. As will be shown, X buffers account for only 1.4% 
of the total buffers.) As the WA collects data, it will transfer the data 
to subsequent portions of the system when larger groupings are advantageous. 

In Figure 6-36, an individual WA consists of V, W, and X buffers and an 
associated Buffer Analyzer (which may be either a dedicated CPU, dedicated micro- 
~jprocessoi% or a sh ared CPU) . _£^ch_WA subunit should be identical so that any j 
-system reconfiguration can take place with the fewest number of problems. The 
BA receives data from and transmits it to the the Resource Monitor. This data 
exchange consists of "data maps" transmitted to the BA, quality information, 
and error messages transmitted to RM, etc. 

In order to size the entire WA system, quantities have to be estimated: 

i = The number of incoming "V" buffers 

j‘ = The number of bytes in each V buffer 

k = The number of W buffers 
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1 = The number of bytes in each W buffer 
m = The number of X buffers 
n = The number of bytes in each X buffer 

Based on given materials, it appears that "i" has to be set to at least 
18. One cannot assume that certain lines are going to be inactive during an 
orbit at this point in time. Operational modes may change, and the system must 
be capable of supporting the full DCS output. 

The number of bytes in each V buffer (j) can be estimated as follows. 

Each input line should be at least "double-buffered 11 to allow the BA enough time 
to make a proper determination of frame type. If it takes a minimum of four minor 
frames to obtain input statistics, it would be wise to hold at least five minor 
frames. To accomodate any size major frame, each "V" buffer would be (4096 bits/ 
minor frame x 5 = 20,480 bits = 2,560 bytes). Therefore, a pair of equal -sized 
V buffers would equal 5120 bytes. 

To size the number (k) of W buffers, it appears that k is at least 18. 

Xhe. tlpperj imi t~'of_k js "unknown - because" 1 1 ' i s' not known how many' types of major 
frames will be present. To circumvent this situation, W buffer could be double 
buffers of the maximum size, and then "k" and "1" could be easily computed. The 
quantity "k" would be (2 x 18) 36 and "1" is simply (4096 bits/major frame x 256 

c r 

minor frames/major frame) 1.05 x 10 bits or 1.31 x 10 bytes each. 

As shown in Section 6.2.1, it would be best to set the last buffers (X) to 
approximately some small multiple of a disk track. Depending on which disk is 
chosen, the sizes v/oul d~be between - ! 3 and - ! Ok bytes", Tor consistency, let the 
number .of X buffers (m) be "48 ’(corresponding” to 48" separate experiment buffers), 
plus 3 (one for "ephemeris’, "one foT'attitude, and one for miscellaneous ancillary 
data), for a total of 51. As stated earlier, the number of bytes for each X 
buffer should be set to 32,768 bytes. 

Thus, the total buffer size in the WA is: 

(i x j) + (k x 1 ) + (m + n) 
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Substituting previously determined values, then the above expression is: 

(18 x 5120) + (36 x 1.31 x 10 5 ) + (51 x 32,768) bytes 

= (9.22 x 10 4 ) + (4.72 x 10 6 ) + (1.67 x 10 6 ) 

= 6.48 x 10 6 bytes 

= 5.18 x lO' 7 bits 

At 0.1 cents/bit ($10 - ^/bit), this buffer would cost $51,834. If 4096 
bit RAMs at about $6.50 each were used,__then the 12, 655 ' units would' be required 
at a cost of $82,257. 

/ 

The ratio of work to be done versus system capability can be expressed 
analytically as "u" of the BA used in the WA. This relationship is identical 
to derivation as discussed in Section 6.2.1. 



1 

f x c 


Where: 


u = computer utilization (%) 
r. = input data in Mb/s. 
s ^ = size of a minor frame in bits 
s^p = size of a major frame in bits 

j = total number of lines of code executed for each minor frame of data 

k = total number of lines of code executed for each major frame of data 

f - multiplicative factor (to convert cycle time to instruction time) 

c = cycle time in seconds of candidate CPU 


And: 

Where • 
For ease 


S MF “ n ( s mf) 

n = integer number of minor frames per major frame 
of data manipulation, the expression for u reduces to: 
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Evaluation of the expression: 


where 


and 


100. c.f .r, 

u - — r 1 (J + 

s mf 


c = .7 us 
f - 3 

j = 225 operations per minor frame 
k = 150 operations per major frame 


r l 

s mf 

n 

u 

(Mb/s) 

(bits) 


(%) 

8 

512 

10 

788.6 

8 

512 

50 

749.0 

8 

:512 

100 

744.0 

8 

,512 

256 

741.0 

8 

1024 

10 

394.3 

8 

1024 

50 

374.5 

8 

1024 

100 

372.0 

8 

1024 

256 

370 5 

8 

2048 

10 

167 7 

8 

2048 

50 

159.2 

8 

2048 

100 

158.2 

8 

2048 

256 

157.6 

8 

4096 

10 

98.6 

8 

4096 

50 

93.6 

8 

4096 

100 

93.0 

8 

4096 

256 

92.6 

12 

512 

10 

1182.9 

12 

512 

50 

1123.4 

12 

512 

100 

1116.0 

12 

512 

256 

1111.5 

12 

1024 

10 

581.4 

12 

1024 

50 

561.7 

12 

1024 

100 

558.0 

12 

1024 

256 

555.7 


r i 

s mf 

n 

u 

(Mb/s) 

(bits) 


(%) 

12 

2048 

10 

295.7 

12 

2048 

50 

280.9 

12 

2048 

100 

279.0 

12 

2048 

256 

277.9 

12 

4096 

10 

147.9 

12 

4096 

50 

140.4 

12 

4096 

100 

139.5 

12 

4096 

256 

138 9 

20 

512 

10 

1971.9 

20 

512 

50 

1872.4 

20 

512 

100 

1860.0 

20 

522 

256 

1852.6 

20 

1024 

10 

985.7 

20 

1024 

50 

936.2 

20 

1024 

100 

930.0 

20 

1024 

256 

926.2 

20 

2048 

10 

492.9 

20 

2048 

50 

468.1 

20 

2048 

100 

465.0 

20 

2048 

256 

463.1 

20 

4096 

10 

246.4 

20 

4096 

50 

234.1 

20 

4096 

100 

232.5 

20 

4096 

256 

231.6 


TABLE 6-14. BUFFER ANALYZER UTILIZATION FACTOR 
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Since the nature of the input data stream is not narrowly defined as 
yet, it would be advisable to examine u with different factors varied. The 
above compact expression, obviously, is very sensitive to certain combinations 
of driving factors. The objective is to determine the worst case which drives 
ud tha.system utilization. -The factors which are relatively fixed are "c" at .7 
us (from sthe minicomputer characterization section), "f" at 3 (to very closely 
approximate load and store operations), "j" at 225 (best known approximation: 

50 for input data accounting, 50 for quality checking, 50 for decommutation, 
and 75 for time validation), and "k" at 150 (best known approximation: 100 
f°r input data accounting, and 50 for quality checking). 


The expression for “u" can be simplified (just for the previous case) to* 


= (100) (.7 x 10~ 6 ) (3) (r.) (225 + 150 

s mf 


4.73 x 10 


(H Q. 67) 
mf m 


Before searching for the worst case, u should be evaluated to establish 
a baseline operating point. 

Typical values are as follows. 

s f = 4096, 2048, 1024, 512 bits 
r = 8, 12, 20 Mb/s 

n = 256, 100, 50, 10 

Table 6-14 provides a range of values for "u" as a function of s^, r , and n 

As can be seen from the table (Table 6-14), as the input data rate goes 
up, the number of J^cessors_to “handle ! Tfie^oTk'goes up, "and" as” the buffer 
size (the minor frame size) goes upi the amount of" vrork to be dbrie~goes “down . ' 

Additionally, the number of minor frames to a major frame has relatively little 
effect on changing the magnitude of utilization factor (i.e., it takes the 
form of .67/n). Table 6-14 is presented graphically in Figure 6-37. 

To summarize, the WA can be defined in terms of hardware and capital 
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FIGURE 6-37. WA UTILIZATION 










expenditure as shown in Table 6-15. Using the information in Tables 6-14 and 
6-15, an illustration showing the projected system (WA only) costs is presented 
in Figure 6-38 as a function of input data rates. A detailed WA is presented 
in Figure 6-39. 
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Work Assembler Attribute: 

Parameter 

Units 

Projected Cost ($) 

Number of Identical WA 
Subunits 

A 

18 

Not Applicable 

Number of Buffer Analyzers 

D 

1 to 18 

$46K ea. 1 

Total Buffer Costs 

Not Applicable 

Not Applicable 

$52K to $83K 3 

Misc. Hardware 

Not Applicable 

1 

$20,000 

Total System Cost 

Not Applicable 

1 

100K + (D) ($46K) 4 


NOTES: 

1. Average pricefor minicompu ter surveyed 

2. 6.48 x TO 6 bytes/system = 5.18 x 10 7 bits/system 

3. At .1 cents/bit {=$.001 bit = $10" 3 /bit): 5.18 x 10 7 x 10‘ 3 = $51,834. If 4096 

bit RAM ICs were used at $6.50 each, then (5.18 x 10'/4096 =) 12,655 x $6.50 = $82,257 

4. Total buffer costs (approximately) + Misc. Hardware ($20K) = $1 00K 


TABLE 6-15. DETAILED WORK ASSEMBLER COSTS 
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6.3.2 


MSS Considerations 


The next step is to consider what possibilities exist for the MSS. 

If 3330 type disks were used in the SOPS, the most convenient scheme would be 

1 2 

to collect “orbit" groups of data. If there are 5 x 10 bits/mission and 
approximately 100 orbits/mission, then there will be approximately 5 x 10^° bits/ 
orbit, or 0,63 x 10^ bytes/orbit. Since a 3300 disc unit holds about 83.0 
x 10® bytes, the quotient of (0.63 x 10^ bytes/orbit)/(83.9 x 10® bytes/umt) 
yields 75.09 disk units/orbit. This, for obvious reasons, rules out 3330 
type discs. However, if one were to use 167.8 x 10 byte removable disk packs, 
then 37.54 disc packs per 100 minutes would be needed. Thus, large disk 
units are not yet impractical. 

The next option uses HDTs as the MSS. Since an orbit's worth of 
data is approximately 5 x 10^® bits, and since a reel of HDT can hold approxi- 
mately 1.4 x IQ 10 bits, the product (5 x 10^® bits/orbit)/(l .4 x 10^® bits/reel) 
yields 3.57 reels of HDT per average orbit. This option becomes more attractive 
when one considers that the HDT can handle a data rate of up to 20 Mb/s. 

To determine the best way to handle bursts of high-rate data, assume 

a worst case burst at 50 Mb/s for 10 minutes. This hypothetical worst case 

in 

burst represents (50 x 10 x 60 x 10) 3 x 10 bits of high rate per orbit! 

This could represent up to (3/5) 60% or an orbit data group. To transfer this 
volume of data (originally entering the DCS at 50 Mb/s), a slow-down of 
only (20 Mb/s)/(50 Mb/s) 1 to 2.5 is required to capture it from the SIPS 
tape recorder. Thus, if the biggest burst of 10 minutes occurs, 25 minutes 
of SIPS playback time is required. Since an orbit's worth of data will occur 
during the 70 to 80% of the projected 100 minute interval, a SIPS lull period 
of between 20 and 30 minutes per orbit could easily be utilized for recording 
the high rate data for better use, and any unprocessed data could be easily 
deferred until the next lull. 

Operationally, it would be advantageous to keep the high rate data 
on separate reels of HDT (3 x 10^® bits/orbit)/l .4 x 10^® bits/reel) = 2.14 
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reels/orbit) so that during deferred output processing, this data base can be 
merged. 


Two parameters (viz., G and H) and the resulting costs have to be 
derived before comparing HDTRs to devices like the Terabit system. The two 
parameters are (G) how many MSS units are required and (H) how many bytes of 
storage are m each unit 7 

For the recording HDTRs, it appears that G = 3 Two units should be 
on-line all of the time, and a third unit should serve as a spare on-line 
unit. The data rates would be no problem since each HDTR could handle up to 
20 Mb/s. H would be equal to 1.4 x 10^° bits, as previously discussed, (It was 
shown earlier that 2 HDTRs plus 1 spare HDTR are required for playback. Thus, 
the total number of HDTRs would equal 5 (G = 5) ). 

When considering a device such as the Terabit system, the primary 
limiting factor restricting its easy utilization is its input data rate - at 
best 9.6 Mb/s (instantaneous), and realistically 5 6 Mb/s. If the average 
incoming data rate were 9 Mb/s, at least two units would have to be connected 
to the WA. Operationally, this would not be any problem, because the WA 
output is easily switched. Since the Terabit system uses tapes that hold 
46.8 x 10 9 bits, then one orbit's worth of data would be held on (5 x 10^ 
bits/orbit)/(46.8 x 10 9 bits/reel), 1.07 reels. (This is clearly an advantage 
over HDTs.) Therefore,, one would have to have 2 units plus one spare on-line 
for recording. (The HDTRs would be required to have 2 additional output units 
plus 1 spare - thus, a total of 5 units.) The tradeoff between the HDTs and a 
Terabit appears to be straightforward. For the price of just 1 Terabit system 
(approximately $1.5M), one could obtain at least 13 HDTR's plus 13 bidirectional 

SCI (13 x (70 + 40)K = $1.43M). ~A ^ p_^pqs_ed_intemediate _MSS^ could, contain 

five (5) HDTRs plus five (5) SCI * s (5 x (70 + 40) = $550K) It is also 
recommended that a small disk (the size of which has not been determined) to 
be present to facilitate quick-look and future P0CC requirements. However, it 
may be unlikely that many submitted SOPS designs would incorporate HDT or 
Terabit because few designers have a good familiarity with them. 
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The next step in examining candidate MSS centers is the use of 6250 

bpi tapes. At least 3 drives would be required for recording incoming data, 

because 2 would be needed to maintain a 10 Mb/s input data rate operationally' 

( viz., a pin gpong~ mode "of operation); Fo ur drives would represent a_ t 20 Mb/s 

capability, and would greatly simplify tape operations. Since each 6250 bpi reel 

g 

can hold approximately 1.2 x 10 bits/reel, and since a hundred minute orbit 
represents about 5 x lO 10 bits, then approximately 41.7 reels (5 x 10 10 /1.2 x 
10 9 ) would be filled. This medium is an attractive possibility because the 
quantity of tapes required is not too high. 41.7 reels every 100 minutes would, 
on the average, be one reel every 2.4 minutes.) 

As far as costs go, four 6250 bpi drives (at $30K each) represent 
about $120,000 together with a single controller (at $38. 6K), which only costs 
$458,600. 6250 bpi drives are clearly more cost-effective than HDTRs ($158.6K 

for 4 drives versus $330K for 3 HDTRs). 

To fit into the overall architecture which was illustrated earlier, 
a separate set of 6250 bpi drives would be required to output the intermediate 
archived data. These drives would have to be independent of the first four 
drives so that scheduling of resources can he accomplished. Thus, the full 
Configuration proposed for the MSS is illustrated in Figure 6-40. 

As illustrated, the MSS consists of 2 pairs (total of 4) 6250 bpi 
drives that ping-pong operationally for the record mode. A spare unit is 
used as a "wild card' 1 in both' the record and' playback portions of the MSS. 

The playback portion of the MSS is identical to record layout. A disk (of 
undetermined size) links the input and output portions of the MSS to facilitate 
quick-look capabilities. 

Figure 6-41 illustrates the cost-curve for the basic hardware that was 
illustrated in Figure 6-39 (less the small disk). As a bare minimum, configura- 
tion of drives (2 in, 2 out, and one spare) can sustain a continuous rate up 
to 10 Mb/s. (10 Mb/s in and 10 Mb/s out). As shown, the next addition 
(two pairs of drives) brings a step to the cost-curve. 

As a conclusion to the MSS discussions, the subject of an automatic 
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tape handling system (such as Calcomp's ATL) will be discussed briefly. Before 
the trade-offs between operators and automatic tape handling are considered, it 
should be stressed that systems such as the ATL require a rather sophisticated 
computer manager (in the ATL, either an IBM 360 or 370, or an emulation). 'The 
choice of devices such as these must be considered only if an overwelming advan- 
tage can be found. Figure 6-41 shows four curves, starting from the bottom of 
the figure: ' ‘ " 

• The cost of one full-time operator and a 10% a year 
raise over 5 years 

• The cost of ten part-time operators and a 10% a year raise 
over 5 years 

• The cost of ten full-time operators and a 10% a year 
raise over 5 years 

• A preferred ATL configuration (2 controllers and slots for 
8 drives) 


Figure 6-42 clearly shows that it is profitable (economically! 
to use such a device. 

6.3.3 Output Processor 

At this point in the processing system we have the following: 

• Blocks of experiment data (decommutated) on approximately 
42 reels of 6250 bpi tape 

9 Uniform work units (same size) 

• A precise (byte-by-byte) map of all experiment (and 
ancillary) data 

• Quality control information that may have come in at 
some time after reception and intermediate storage of 
experiment data 

• High-rate bursts of data (both overlapped data that 
was recorded and transmitted later, and high bit rate 
experiment data) blocked into uniform work .units. 
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The preceding allows for ajsijiipl_e_and_ straightforward^ output 
processor configuration as illustrated in Figure 6-43. As shown, it is highly 
modular, flexible, and resistant to single-point failure. A general data 
walkthrough is presented m the following paragraphs^ Detailed design consider- 
ations follow that. 

Blocks (or work units) of decommutated experiment data are transferred 
from the 6250 bpi transports (units 1 through G) to waiting memories (units 
1 through L) via a DMA channel. The entire work unit is buffered, and these 
blocks are linked to other blocks to form larger blocks. As soon as a conven- 
iently large experiment data file is assembled, the experiment file is then 
sent to a staging disk. When a significant amount of experiment data is built 
up on the staging disk, an output data product is written. The CPU acts strictly 
as a data manager in the task of linking data blocks. If missing data is not 
input to the system, fill data is substituted. 

1 2 

To set broad operational limits, it shall be assumed that 5x10 
bits/mission are to be processed. With approximately 100 orbits/mission, then 
5 x 10^ bits/mission is derived. If this data were to go through the facility 
(viz., the output processor) in about 100 minutes (100 minutes/orbit), then the 
statistical data rate would be (5 x 10 10 bits/orbit)/(100 x 60 sec/orbit) = 

8.33Mb/s. It would therefore be prudent to design to at least 16 Mb/s (or 
__20 .Mb/s) to allow "for adequate operator. rest.. pen ods repa i rs .etc . 

Detailed Data Flow 

A set of 6250 bpi tapes containing a set of experiment data are selec- 
ted and mounted for playback. The quantities of tapes containing an experiment's 
data - coul d' be’~between 1 and 42 reels.'" Ordinarily,' most' reeTs contain the regular' 
low and medium-rate experiment data. The regular data, for example, would be 
played back on transport #1 and the high-rate burst data on transport irG. The 
RM would set up the playback of high-rate data so that its data would be 
placed in the approximate GMT time slot so.. that the removal of overlapping data 
and chronological ordering functions could be easily performed /jThis” is’il lus- 
trated in Figure 6-44. The intent at this point is to line up work units for linkage 
processing so that a minimum amount of data handling is required. 
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FIGURE 6-43. OUTPUT PROCESSOR BLOCK DIAGRAM 
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The next step is to examine the attributes and functions of the "L" 
memories as shown in Figure 6-43. Assuming these memories are linked to the 
"K" CPU's (K does not necessarily equal L), the maximum DMA Rate (as selected 
from Table 4-7) is (2.5 M words/sec. x 16 bits/word =) 40 Mb/s. It should be 
pointed out that this value is a computed average and many minicomputers (for 
example) could be faster. In general, the DMA rates can be expressed as: 

r dma = r in + r out + Overhead 


where: 


R DMA = ^MA channel rate (~40 Mb/s) 

Rj N = Input channel rate (~ 20 Mb/s) 

R = Output channel rate (~20 Mb/s) 

K 0UT 

It has been found in past experiences that RqvERHEAD can amount 
to 10% of R DMA in most good memory systems. Thus, for a steady state situation, 
R IN = R 0UT “ ^ Mb/s. This appears to be entirely acceptable. 

The output processors CPU (1 through k) as illustrated in Figure 6- 
shall perform the following operations on data within the previously discussed 
memories: 

9 Output data accounting 

• Quality checking 

• Overlap removal 

a Data fill 

s Merging ancillary data 

9 Data store 

It would now be appropriate to consider the same type of computational 
unit which was utilized in the Work Assembler, i.e., the average minicomputer 
as earlier specified in Table 4-7. 

The work load for the output processor was specified in Table 4-11 
and is summarized: 
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Estimated lines of code executed per: 

Function 

m.f. 

j 

M.F. 

Orb. G. 

Exp. File 

Output data accounting 

50 

100 

5000 x E 

mm 

Quality check 

50/200* 

50/200* 

500 x E 


Data Store 

0 

0 

5000 x E 

SSI 

Overlap Removal 

0 

0 

20000 x E 

0 

Data fill 

0 

0 

5000 x E 

10,000 

Merging ancillary data 

0 

° 

5000 x E 

0 

Subtotals 

100 

150 

40500 x E 

75,000 


* Second value for deviant conditions 


Thus, one of the tools to determine the acceptability of the candidate 
computation unit is a determination of the system utilization (u) factor. This 
relationship can be expressed as: 



f x c 


Where: 


u = computer utilization (%) 
r = input data in Mb/s 

j = total number of lines of code executed for each minor frame of data 
1 = total number of lines of code executed for each orbit group 

m = total number of lines of code executed for each experiment file 

k = total number of lines of code executed for each major frame of data 

f - multiplicative factor (to convert cycle time to instruction time) 

c = cycle time in seconds of candidate CPU 

s^ = size of a minor frame in bits 
Sj^p = size of a major frame in bits 


205 













Sg G = size of an orbit group in bits 
s £ p = size of an experiment file in bits 

And: S MF ’ n ( s mf) 

Where: n = integer number of minor frames per major frame 


For ease of data manipulation, the expression for u reduces to 


u = 100 ♦ c 




+ 


1 

S 0G 


+ 



Since the nature of the input data stream is not narrowly defined as 
yet, it would he advisable to examine "u" with different factors being varied. 

The above compact expression is very sensitive to certain combinations of driv- 
ing factors. The objective is to determine the worst case which drives up the 
system utilization. The factors which are relatively fixed are "c" at .7 us 
(from the minicomputer characterization section), "f“ at 3 (to very closely 
approximate load and store operations), "j" at 100 (best known approximation), 
and "K" at 150 (best known approximation) , "1" at 40,500 x E~( best' known approxi- 
mation) ,_and_J|m" at 75,000 x E Chest" known_approximation) . 


to: 


The expression for "u" can be simplified (j'ust for the previous case) 


u = (100) (.7 x 10~ 6 ) (3) r. 




'100 + 150 + 40500 x 48 


n 


5 x 10 


10 


75000 x 48 
(5 x 10 1 2 )/4S 


(2.1 x 10' 4 ) r . 


" 

100 
S X 

(l + 

+ 

7.34 x 10' 5 

mf 

\ " / 




Before searching for the worst case, u should be evaluated to establish 
a baseline operating point. Typical values are as follows: 


s mf = 4096, 2048, 1024, 512 bits 


206 



r. = 8, 12, 20 Mb/s 
n = 256, 100, 50, 10 

Table 6-16 and Figure 6-45 illustrates these findings. Table 6-17 summarizes 
the projected cost and Figure 6-46 illustrates the cost curves. 
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TABLE 6-16. OUTPUT PROCESSOR UTILIZATION FACTOR 
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INPUT DATA RATE {r,J - Mb/s 


s mf = 4036 s mf = 2048 s mf = 1024 



FIGURE 6—45 . OUTPUT PROCESSOR UTILIZATION FACTOR 
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ATTRIBUTE PARAMETER UNITS PROJECTED COSTS ($) 


Total Memories 1 

L 

1 to 20 

— 

Number of Bytes in 
Each Memory^ 

M 

52 

— 

Total Buffer 3 or 
Memory Costs' 3 

(L X M) 

(52) (L) 

(I) 46,000 

Number of output 
Processors 

K 

1 to 20 

46,000 ea. 

4 

Mi sc. Hardware 

- 

1 

$20,000 

Total System Costs 

- 

1 

20,000 + K(l.l) (46,000) 


NOTES: 

1. It is assumed L = K; i.e., one memory to each 

2. 4 buffers @ 13K = 52K bytes 

3. This cost would be core costs associated with each CPU. It will be 

assumed that this core cost is about (an additional) 10% of a CPU cost. 

4. Projected cost; standard interface electronics. 


TABLE 6-17. OP PROJECTED COSTS 





FIGURE 6-46. OUTPUT PROCESSOR COST CURVES 
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6.3.4 Peripheral Pool 
Same as 6.2.4 

6.3.5 Resource Monitor 
Same as 6 2.5 
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7.0 SUMMARY OF ADVANTAGES AND DISADVANTAGES 

This section of the study enumerates the significant advantages and 
disadvantages of each of the proposed architectures. These advantages and dis- 
advantages are not necessarily diametrically opposed to one another. 

Architecture Number 1: 

Work Assembler 


Mass Storage System 

o HDTRs can easily keep up 
with data stream. 

e A minimum amount of reels 
of tape are processed. 

• Sequential blocks of 
data are hard to 
locate for playback. 

a Bit error rate for 
HDT is higher than 
desirable. 

Output Processors 

« Considerable confidence 
can be placed on the 
output data processing 
because late incoming 
status data can be easily 
incorporated. 

; • Output processors may 
be susceptible to un- 
even work assignments 
because captured data 
is not grouped toge- 
ther. 



« Staging of data from 
MSS to output processor 
could be hampered by 
small number of source 
tapes. 



« Data Decommutation map 
has to be passed again 
to Output Processor. 


Advantages 


Disadvantages 


• Errors in decommutation 
map will not destroy in- 
tegrity of data base. 

« A very effective data 
rate smoothing effect is 
performed. 

9 A minimal amount of data 
analysis and data manipu- 
lation is performed. 


• Possible problem when 
one cnannel is greater 
man 8 md/s (up to 
16 mb/s) 
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Architecture Number 2 


Advantages Disadvantages 


Work Assembler 9 No significant advantages 

were identified. 

9 Mistakes (due to faulty 
decommutation data or 
otherwise) could be 
very hard to recover. 

Mass Storage System a 6250 bpi tape drives are 

amendable to Cal comp ATL 
adoptation. 

9 Large number (~45) of 
tape reels simplify output 
data process! ngr 

« Cost of an additional 
ATL computer could 
offset the cost advan- 
tage of an ATL. 

Output Processors 0 There is minimal amount of 

data handling and manipu- 
lation. 

9 Design can easily handle 
decommutation if required 
in error-recovery mode of 
operation. 

» No serious disadvantages 
were identified. 
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8.0 


RANKING OF ARCHITECTURES 


In addition to the advantages and disadvantages as tabulated in Section 
7, there are two additional ranking criteria: 

« Point ratings of each architecture 

t Total system costs 

Table 8-1 provides a function-by-function rating of each architecture. Both 
architectures were designed to earn the highest possible rating; and the points 
assigned to each architecture proved to be quite similar. The normalized total 
point scores reveal, therefore, that the two architectures are equivalent in 
terms of function. The projected cost differentials tell a different story. 

System costs can be projected in terms of two (system) operating 
points. A "full up" system would be best sized to handle up to 8 Mb/s for 
the Work Assembler and first half of the Mass Storage System; and 12 Mb/s for 
the second half of the Mass Storage System and the Output processors. A low- 

high cost for each system block is provided in Table 9-2. The low-high costs are 
based on 100% and 50% confidence factors used in sizing the software portions 
(specifically the "estimated lines of code executed" as tabulated in Table 4-11) 
of the system. Table 8-2 indicates that Architecture 2 is less costly. 
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TABLE 8-1. RATINGS OF ARCHITECTURES 


SECTION 2 
PAR. NO. 

BRIEF STATEMENT 
OF 

SPECIFICATION 

ASSIGNED 

WEIGHT 

(i-io) 

5 

RATINGS 

ARCHITECTURE 1 

ARCHITECTURE 2 

2.0 

• Modularity 

• Expandability 

8 

8 

10 

6 

10 

10 

2. 1.1.1 

• Data Characterization 

9 

Output Processors 
8 Work Load is more 
complicated than Arch. 

2. 

10 

• Experiment Mix Profile 

9 

8 

.. ... 

10 

2. 1.1.2 

• Tapes 

10 

10 

10 

• Communications 

7 

10 

10 

e Data Volumes 

10 

10 

10 

2. 1.1.3 

• Throughput 

10 

10 

10 

2. 1.2.1 

• Update Input Accounting 

10 

6 Accounting, is kept on 
R<p c <jinjung basis instea 

6 Same as Architecture #1 

2. 1.2.2 

o Update Output Accounting 

10 

7 System data flow does 
not reflect the full 
data 

7 Same as Architecture #1 

2. 1.2. 3 

• Quality Check 

10 

10 Accountability 

10 

2. 1.2.4 

e Receive and Sort TLM 

• Receive and Sort Ephemeris 
arrd Attitude 

10 

10 

8 Technique of data sto- 
rage makes difficult 
retrieval for output 
processing 

8 Decommutation of Data 
on-the-fly is potential- 
ly nskly if error in 
given info, is not 
immediately passed onto 
to SOPS 

a E & A Data 

10 

8 ' 

8 






























TABLE 8-1. | RATINGS OF ARCHITECTURES, (CONT'D.) 


SECTION 2 
PAR. NO. 

BRIEF STATEMENT 
OF 

SPECIFICATION 

ASSIGNED 

WEIGHT 

(1-10) 

RATINGS 

ARCHITECTURE 1 

ARCHITECTURE 2 

2. 1.2.5 

• Merge Ancillary 

10 

8 

10 

2. 1.2.6 

• Creating and accessing files 

10 

6 Cumbersome way of stor 

■ 6 Same as Architecture #1 




ing data for access by 



o Allocate, log, and record 

10 

the output processor 

7 




7 X99 h m^h interaction 


2. 1.2.7. 1 

•Time Validation 

5 

10 

10 

2. 1.2. 7. 2 

« Remove overlapped data 

10 

8 Overlapped data may be 
on same HPT 

10 

2. 1.2.8 

• Coordinate Transformation 

8 

10 

10 


e Ancillary data 

8 

8 

9 

2. 1.2.9 

• Interpolate attitude 

5 

10 

10 


e Coordinate transformation 

8 

10 

10 


• Ancillary Attitude computa- 





tions 

8 

10 

10 

2.1.3 

• Modularity 

8 

10 

10 


• Capacity 

10 

10 

.9 


• Error Rates 

10 

6 HDT error rate to high 

10 


• Technology 

9 

8 

10 


• Media 

7 

10 

10 


• Maintainability 

9 

8 HDT set up difficultie 

s 10 























TABLE 8-1. 


RATINGS OF ARCHITECTURES , (CONT'D.) 


I 


SECTION 2 
PAR. NO. 

BRIEF STATEMENT 
OF 

SPECIFICATION 

ASSIGNED 

WEIGHT 

(1-10) 

i 

RATINGS 

ARCHITECTURE 1 

ARCHITECTURE 2 

2.1.3, cont'd 

• Availability 

8 

8 Both architectures have 

8 




only one data bus shown 



• Interface 

8 

10 which will effect 

10 


1 


running in a degraded 



• Persi stance 

8 

10 mode, if a bus failure 

10 




occurs 



• Self-test 

8 

9 

9 


• Transfer rate 

10 

10 

9 


• Transferability 

10 

9 

10 

2.1.4 

• Convert to experiment format 

10 

10 

10 


• Write to tape 

10 

10 

10 

2.1.5 

t Transmission Rate 

10 

10 

10 


0 Switched Circuit 

10 

10 

10 


e Packet Switched 

10 

10 

10 

2.1.6 

a Operations 

9 

8 

8 


o Personnel 

9 

8 

8 


0 Reliability and Availability 

9 

9 

10 


0 Maintenance Support 

9 

10 

10 




5 Too difficult to acces 

> 9 

2.2.1 

0 Quick Look 

3 

data from HDTs. 


















TABLE 8-1. i RATINGS OF ARCHITECTURES, (CONT'D.) 

! i 


SECTION 2 
PAR. NO. 

BRIEF STATEMENT 
OF 

SPECIFICATION 

ASSIGNED 

WEIGHT 

(1-10) 

RATINGS 

ARCHITECTURE 1 

ARCHITECTURE 2 

2.2.2 

• Process data for GSFC POCC 

3 

5 Data will not be 
available for quickloo 

6 processing, because of 
HDT still storing 

10 input data. 

9 

< 


• Retrieve data 

3 

8 


a Format data 

3 

10 


• Transfer data to POCC 

3 

7 

10 

TOTAL POINTS 



3660 

3880 

MAXIMUM POINTS 


419 x 10 

4190 

4190 

NORMALIZE ■ 
POINT SCORES 



8736 

.9260 


TABLE 8-2. PROJECTED SYSTEM COSTS 
(HARDWARE ONLY) 



Architecture Costs 

For: 

Approx 

SOPS 



C $) 


Cost 

Distri- 

Subsystems 


1 

/■ 

c 


buti on 


Low 

High 

Low 

High 

{%) 

Work Assemblers 

204 

388 

468 

836 

25 

Mass Storage System'*' 

330 

330 

347 

347 

15 

Output Processors 

765 

1,470 

324 

627 

20 

Output Staging Devices 

210 

290 

210 

290 

10 

Output Peripheral Fbol 2 

600 

600 

600 

600 

20 

Resource Monitor 

228 

322 

228 

322 

10 

TOTALS: 

2,337 

3,400 

2,177 

3,022 

ioo : 


1. MSS for Architecture 1 consists of HDTRs, Architecture 2 uses 6250 
bpi drive without the CALcomp ATL. 

2. 56 Kb/s modem costs not included. 
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APPENDIX A 

✓ 

LIST OF ACRONYMS AND ABBREVIATIONS 
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LIST OF ACRONYMS AND ABBREVIATIONS 


BA 

Buffer Analyzer 

bpi 

bits per inch 

CCT 

Computer Compatible Tape 

DBM 

Data Base Management 

DMA 

Direct Memory Access 

E/A 

Ephemeris and Additude 

ESA 

European Space Agency 

FS 

Frame Synchronizer 

GEI 

Geocentric Equatorial Inertial 

GMT 

Greenwich Mean Time 

GSFC 

Goddard Space Flight Center 

GSTDN 

Ground Spaceflight Tracking and 
Data Network 

HDT 

High Density Tape 

HDTR 

High Density Tape Recorder 

IC 

Itegrated Circuit 

IPD 

Information Processing Division 

ips 

inches per second 

JSC 

Johnson Space Center 

Kb/s 

Kilobits per second 

Mb/s 

Megabits per second 

MCC 

Mission Control Center 

MSS 

Mass Storage System 

O&A 

Orbit & Attitude 

OP 

Output Processor 

POCC 

Payload Operations Control Center 

QC 

Quality Control 

RAM 

Random Access Memory 

RM 

Resource Monitor 

SCI 

Serial Controller Interface 

SDPF 

Space! ab Data Processing Facility 
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LIST OF ACRONYMS AND ABBREVIATIONS, (CONT'D.) 


SEI 

Solar Ecliptic Inertial 

SIPS 

Spacelab Input Processing System 

SOPS 

Spacelab Output Processing System 

TDRS 

Tracking and Data Relay Satellite 

TLM 

Telemetry 

WA 

Work Assembler 
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